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INTRODUCTION 


The  development  of  a  civilian  corps  of  first  responding  emergency  medical  technicians  (EMT) 
and  paramedics  during  the  past  several  decades,  which  was  in  many  ways  an  extension  of  that 
which  has  long  existed  among  military  corpsmen,  has  had  a  very  positive  impact  on  the  survival 
of  all  types  of  injuries  and  acute  illnesses.  The  reality  is,  however,  that  the  interpretation  of  a 
victim’s  clinical  problems  and  therapies  instituted  are  at  this  time  dependent  upon  the  individual 
caregiver’s  training,  judgment,  and  experience.  It  is  hypothesized  that  having  a  virtual  physician 
present  at  the  scene  through  the  technology  of  modem  telecommunications  will  have  a  favorable 
impact  on  patient  outcome  in  many  instances.  Through  the  application  of  telecommunication 
technologies.  The  University  of  Texas  Health  Science  Center  at  Houston  (UTHSCH)  proposes  to 
virtually  bring  the  physician  to  the  scene  of  the  incident,  thereby  allowing  online  physician 
evaluation  and  intervention. 

With  recent  advances  in  telecommunication  technology,  it  is  now  possible  to  decrease  even 
further  the  time  lapse  between  the  incident  and  the  institution  of  appropriate  therapy  utilizing 
digital  technology  to  transmit  real  time  physiologic  data  and  two-way  audio  visual 
communications  (see  Figure  1).  It  will  be  possible  to  have  physicians  present  on  the  battlefield  or 
the  highway,  mentoring  the  first  responding  medical  personnel  which  will  improve  outcomes  in 
many  instances  through  improved  diagnoses,  implementation  of  lifesaving  procedures,  and 
institution  of  definitive  treatments.  Wherever  possible,  new  military  technologies  for  combat 
casualty  care  will  be  integrated  into  the  program. 


GPS  Satellite 


Medical  Control 
(Physician’s  Station) 


Figure  1.  Digital  EMS  Overview 
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DREAMS™  builds  upon  an  earlier  United  States  Army  Medical  Research  and  Materiel 
Command  (USAMRMC)  DAMD  17-98-2-8002,  the  USAMRMC  DAMD 17-00-2-00 10 
collaborative  project  at  The  Texas  A&M  University  System  (TAMUS)  (January  21,  2000),  and 
the  Advanced  Research  Projects  Agency  (ARPA)  sponsored  project  titled  “Advanced  Fire 
Protection  Technologies”  (June  23, 1995).  In  the  ARPA  project,  The  University  of  Texas  Health 
Science  Center  at  Houston  (UTHSCH)  tested  a  prototype  “Emergency  Information  Resource  and 
Response  Management  System.”  This  proposal  is  the  no-cost  extension  to  the  DAMD  17-98-2- 
8002  for  the  period  of  performance  to  end  October  31, 2003. 
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ANNUAL  REPORT  BODY 


In  line  with  the  scope  of  work  (SOW)  for  DAMD  17-01-2-0054,  this  report  addresses  each  SOW 
item.  Individual  items  may  have  references  included  in  the  appendices  of  this  report. 

a.  Work  with  The  Texas  A&M  University  System  (TAMUS)  to  Enhance  Current 
Technologies  within  the  Digital  EMS  Vehicle  and  Associated  Hospital  Systems.  UTHSCH 
concentrated  work  in  two  main  areas  to  improve  the  vehicle  systems.  First,  additional 
ambulances  were  put  into  the  procurement  process,  and  detailed  medical  user  testing  has  begun 
on  the  Digital  EMS  software  and  hardware. 

During  the  past  project  year,  UTHSCH  completed  specifications  for  the  order  of  2 
additional  ambulances.  UTHSCH  has  proceeded  with  the  RFP  process  for  the  order  of  these  2 
additional  ambulances.  This  purchase,  approved  in  the  DAMD  17-98-2-8002  no-cost  extension, 
experienced  delays  due  to  the  long  build  time  to  correct  defective  Ford  truck  chassis  and  due  to 
complete  new  Digital  EMS  technical  modifications  for  the  vehicle  TAMUS  currently  has  under 
contract  with  Frazer,  Inc. 

Quotations  have  been  received  for  the  base  Frazer  ambulances.  Orders  have  been  placed 
for  2  additional  Frazer  units,  with  Digital  EMS  modifications  to  be  placed  under  a  separate  order 
once  the  TAMUS  modifications  are  complete. 

Once  final  specification  changes  are  completed  by  TAMUS  on  the  vehicle  they  procured, 
the  UTHSCH  order  will  be  placed  that  include  modifications  specific  to  the  Digital  EMS 
equipment  planned  for  installation. 

To  improve  the  onboard  Digital  EMS  systems,  the  UTHSCH  medical  user  test  bed  was 
established  at  the  Institute  of  Biosciences  and  Technology  (IBT)  in  the  Texas  Medical  Center, 
Houston.  Shown  in  Figure  2,  the  medical  user  test  bed  includes  a  physician’s  workstation  and  a 
mockup  of  an  ambulance  complete  with  cameras  and  medical  monitoring  equipment. 


Figure  2.  Medical  user  test  bed  at  IBT 


Used  for  both  medical  evaluation  of  the  onboard  systems,  and  training  for  both  physicians  and 
emergency  medical  technicians  (EMTs),  the  medical  user  test  bed  will  prove  invaluable  as  the 
project  moves  forward  to  field-testing  in  the  coming  year.  Through  careful  study  and  planning 
for  how  both  physicians  and  EMTs  interact  with  the  Digital  EMS  systems,  better  operational 
protocols  will  be  developed. 
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The  UTHSCH  School  of  Health  Information  Sciences  (SHIS)  completed  an  initial  user 
evaluation  study  at  the  end  of  the  last  year.  The  SHIS  study  focused  on  how  a  medical  user 
(physician  or  EMT)  would  use  the  system,  and  how  to  make  the  system  more  user  friendly. 
Over  the  past  year,  the  UTHSCH  SHIS  usability  team  completed  three  major  tasks. 

1-  Usability  evaluation  of  Digital  EMS  Version  1 .0.  As  part  of  a  comprehensive 
usability  project,  UTHSCH  conducted  a  heuristic  evaluation  of  DEMS  1.0  (physician, 
paramedic,  and  driver  stations).  Fourteen  usability  heuristics  were  applied  to  identify  usability 
problems.  The  14  usability  heuristics  were  violated  161  times  (all  3  workstations  combined). 
Visibility  and  Consistency  are  the  2  heuristics  with  the  most  violations  (48  and  29,  respectively). 
The  next  one  is  Match  with  22  violations.  There  are  6  catastrophic  violations  that  received 
severity  ratings  over  3.50 — it  is  imperative  to  fix  them.  Forty-eight  violations  are  major 
violations  (severity  ratings  between  2.50  and  3.50)  that  are  important  to  fix  and  should  be  given 
high  priority.  Twenty-seven  violations  are  minor  violations  (between  1.50  and  2.50)  that  have 
low  priority  in  fixing.  Also,  there  is  1  cosmetic  problem  that  does  not  need  be  fixed  unless  extra 
time  is  available. 

The  paramedic’s  station  has  the  largest  number  of  violations  (45).  The  physician’s  and 
driver’s  workstations  had  19  and  18  violations  identified,  respectively.  The  average  severity 
ratings  of  all  3  workstations  is  over  2.50,  indicating  that  these  are  major  usability  problems  that 
should  be  fixed  with  high  priority.  For  every  heuristic  violation,  a  potential  solution  was 
recommended.  The  recommendations  were  well  received  by  the  developers  and  most  of  them 
were  considered  in  the  revision  of  DEMS. 

2.  Performed  a  preliminary  usability  evaluation  of  Digital  EMS  version  2  mockup. 
UTHSCH  performed  a  heuristic  evaluation  of  Digital  EMS  version  2  mockup  that  is  being 
developed  to  target  Liberty  County.  Fourteen  usability  heuristics  were  applied  to  identify 
usability  problems.  Forty-seven  violations  were  found  in  the  14  usability  heuristics  for  higher- 
level  usability  design  in  the  mockup.  Visibility  and  Match  are  the  2  heuristics  with  the  most 
violations  (13  and  9,  respectively). 

The  next  2  categories  are  Consistency  and  Language,  each  with  7  violations.  There  are  2 
catastrophic  violations  that  received  severity  ratings  over  3.50 — it  is  imperative  to  fix  them. 
Fifteen  violations  are  major  violations  (severity  ratings  between  2.50  and  3.50)  that  are  important 
to  fix  and  should  be  given  high  priority.  Nine  violations  are  minor  violations  (between  1.50  and 
2.50)  that  have  low  priority  in  fixing.  For  every  heuristic  violation,  UTHSCH  recommended  a 
potential  solution. 

3.  Task  analysis  of  Digital  EMS  version  2  mockup.  SHIS  performed  cognitive  task 
analyses  on  several  tasks  using  the  version  2  mockup.  The  purpose  of  the  task  analysis  is  to 
identify  deeper  usability  problems  that  cannot  be  identified  through  heuristic  evaluation.  SHIS 
used  hierarchical  task  analysis,  GOMS  analysis,  and  distributed  cognition  analysis  as  three 
techniques  in  the  tasks  analysis.  For  a  task  that  is  not  well  structured,  an  alternative  was  proposed 
that  is  again  subject  to  the  task  analysis.  The  current  and  proposed  alternatives  are  compared  to 
demonstrate  the  problem  with  the  existing  task  and  the  advantage  of  the  proposed  alternative. 
The  work  is  still  in  progress. 

Full  reports  on  the  SHIS  evaluation  are  included  as  Appendices  1  and  2.  TAMUS  is 
currently  revising  the  onboard  software  specific  to  the  Liberty  County  Emergence  Medical 
Service  (LCEMS)  in  Liberty,  Texas.  This  is  the  first  of  3  planned  field-testing  locations,  with 
LCEMS  field  deployment  scheduled  to  begin  during  the  first  quarter  of  2003.  The  medical  user 
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test  bed  will  be  loaded  with  the  revised  LCEMS  software  once  completed  and  will  be  tested  for 
user  acceptance  by  SHIS  before  field-testing  begins  in  Liberty  County,  Texas, 

b.  Enhance  the  Existing  Digital  EMS  System  to  Accommodate  Additional  Functionality. 
The  Naval  Research  Laboratory  continued  its  motion  data  collection  using  the  ambulance  gyro 
(and  ambulance  satellite  terminal,  or  AST)  mounted  on  a  Unites  States  Marine  Corps  HMMWV 
(See  Figure  3).  The  terminal  was  then  installed  on  test  bed  vehicle,  a  1988  Ford  ambulance 
modified  to  accept  the  satellite  terminal  (See  Figure  3),  for  further  motion  analysis  and  study. 


Figure  3.  HMMWV  and  Satellite  Test  Bed  Vehicles 

The  AST  graphical  user  interface  (GUI)  was  fundamentally  completed,  with  all  modules 
tested  and  operating  and  providing  a  simple  user  interface.  Upon  direction  from  the  project 
manager,  no  further  work  will  be  conducted  on  this  task  until  the  new  fiscal  year  once  interaction 
with  Texas  A&M  and  their  software  is  conducted. 

NRL,  along  with  the  DEMS  program  office,  developed  specifications  for  the  Ku/Ka-band 
hub  to  be  installed  at  UTHSCH,  and  also  assisted  in  the  selection  process.  UTHSCH  released  a 
RFP  on  the  satellite  terminal  to  be  located  on  the  roof  of  the  IBT  facility.  Proposals  were 
received  and  evaluated.  The  terminal  contract  is  under  negotiation  currently,  with  installation 
slated  to  begin  in  early  2003. 

NRL  provided  input  on  terminal  performance  and  monitor  and  control  software  to  Digital 
EMS  team  members. 

The  NRL  GUI  was  developed  with  a  multi-tiered  access,  to  permit  operators  access  to 
some  layers,  but  to  only  allow  technicians  access  to  parameters  that  could  detrimentally  affect 
the  performance  of  the  AST.  Task  will  be  extended  into  FY03 . 

NRL  continues  to  interact  with  multiple  satellite  vendors  regarding  future  Ka-band 
opportunities,  including  Telesat  Canada  (Anik),  Panamsat  and  Loral  Skynet. 

NRL  has  a  separate  funding  agreement  with  USAMRMC.  Complete  documentation 
regarding  the  NRL  satellite  development  can  be  found  in  documentation  submitted  under  that 
award  and  is  not  included  here. 

e.  Evaluate,  Select,  and  Coordinate  Decision  Support  Technologies  for  Clinical  and  Non- 
Clinical  Decision  Support  Needs  of  the  Digital  EMS.  No  new  developments  regarding  GLIF 
adoption  have  occurred  this  quarter.  We  will  be  talking  with  investigators  at  Columbia 
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University  about  GLEE  (GLIF  execution  engine)  during  the  AMIA  Fall  Symposium  2002  in 
November,  but  as  a  final  decision  on  the  expression  language  has  not  yet  been  made,  no  GLIF  3 
execution  engine  can  be  developed.  Current  plans  call  for  the  re-expression  of  DEMS  prehospital 
care  algorithms  and  protocols  as  Arden  Syntax  MLMs  during  Q2  and  Q3  of  2003.  The  UTHSCH 
Digital  EMS  staff  has  been  tasked  to  complete  this  development. 

d.  Evaluate  and  Select/Adapt  Emergency  Medical  Data  Set  and  Information  Model  for  use 
with  Digital  EMS.  As  a  first  step  to  the  development  of  the  information  model  and  data  set  to  be 
used  on  the  ambulances,  die  Digital  EMS  staff  performed  a  software  functional  analysis  included 
in  Appendix  3.  The  analysis  included  a  software  development  plan  calling  for  several  key 
elements  to  ensure  a  quality  product.  These  areas  are:  customer  requirements  definition, 
functional  requirements  definition,  testing  plan  (includes  independent  verification  and  validation 
in  a  dedicated  testing  environment),  and  emergency  scenario  based  testing  scripts.  Together  these 
elements  will  provide  a  foundation  to  test  the  Digital  EMS  software.  This  document  focused  on 
the  documenting  of  DEMS  software  development  including  the  interagency  interactions  (policy 
and  procedure)  specifications  and  diagrams. 

A  final  data  dictionary  has  been  negotiated  with  our  TAMUS  partners.  TAMUS  has  the 
final  implemented  data  dictionary;  however  the  final  proposal  from  UTHSCH  that  was  used  in 
the  negotiation  process  is  attached  as  Appendix  4.  There  are  208  main  concepts  and  587  codes 
that  may  be  used  to  fill  in  the  coded  concepts.  In  addition  to  the  data  dictionary,  UTHSCH  has 
developed  a  database  schema  for  persistent  storage  of  patient  information  in  an  operational 
system.  This  schema  may  also  be  used  for  persistent  storage  at  Liberty  County  EMS.  This 
schema  is  shown  in  Appendix  5  attached.  The  design  rationale  and  goals  are  best  stated  by 
Ms.  Vijaya  Mekala;  ^ 

“Prehospital  EMS  is  a  system  that  ensures  that  patients  with  acute  traumatic  and  medical 
conditions  are  provided  medical  care  outside  the  hospital  and  are  transported  to  an  appropriate  medical 
facility.  These  systems  vary  in  their  ability  to  collect  patient  and  systems  data  and  to  put  these  data  to  use. 
To  facilitate  the  proper  usage.  EMS  systems  must  have  methods  of  collecting  and  sharing  it  with  others. 
As  with  other  medical  specialties,  EMS  providers  also  are  required  to  prove  their  effect  on  patient 
outcome  as  a  justification  for  their  existence.  This  database  is  designed  in  a  generic  way  so  that  it  would 
not  only  collect  the  ambulance  and  patient  information  but  also  connect  to  the  local  hospital  database, 
facilitating  research  efforts,  facilitate  billing  and  reimbursement,  and  providing  valuable  information  on 
other  issues  or  areas  of  need  related  to  EMS  care.  The  database  can  be  modified  and  is  scalable 
according  to  the  needs,  constraints,  and  special  considerations  of  the  project.  These  include,  but  are  not 
limited  to,  any  preferred  software  packages,  considerations  of  business  rules,  time  constraints,  and 
overall  goals  and  objectives  of  the  completed  software.  ’’ 

e.  Develop/Evaluate  Online  Treatment  Protocols.  The  Liberty  County  EMS  personnel 
have  adopted  new  medical  protocols  which  necessitated  the  recoding  of  portions  of  existing  text- 
based  protocols,  as  reported  in  the  October  2002  TSR.  UTHSCH  has  reformatted  these  protocols 
for  display  in  the  Digital  EMS  systems,  and  TAMUS  has  integrated  the  changes  into  the  software 
revision  currently  underway  for  Liberty  County  EMS.  See  Appendix  6. 

As  was  discussed  above,  SHIS  completed  the  phase  I  user  evaluation  study  of  the  Digital 
EMS  software.  The  new  LCEMS  software  will  be  evaluated  by  the  SHIS  team  once  the 
completed  treatment  protocols  are  loaded  in  the  IBT  medical  user  test  bed.  This  evaluation  is 
slated  to  begin  during  the  first  quarter  of 2003. 

f.  Integrate  Online  Treatment  Protocols  and  Medical  Records  Information  into  the 
Existing  System  for  Enhancing  System  Functionality.  Integration  of  the  online  treatment 
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protocols  and  medical  records  information  is  still  on  hold  pending  the  finalization  of  the  data  set 
and  information  model  and  the  evaluation  of  the  treatment  protocols.  UTHSCH  and  TAMUS 
have  had  a  series  of  joint  task  force  meetings  to  address  this  challenge.  The  2  partners  are  in 
agreement  on  the  strategic  objectives  and  final  goals  for  integrating  treatment  protocols  and 
medical  records  information,  but  there  are  still  some  initial  hurdles  to  be  overcome,  UTHSCH 
completed  data  model  and  data  dictionary  studies  in  the  past  year.  These  are  included  as 
appendices  as  referenced  above . 

g.  Enhance  the  Existing  Infrastructure  for  Supporting  a  Network  of  Multiple  Digital  EMS 
Vehicles  and  Hospital  Systems  in  an  Integrated  Environment.  UTHSCH  has  formulated  an  initial 
plan  for  linking  Memorial  Hermann  Hospital  (MHH)  with  private  fiber  to  the  IBT  facility. 
UTHSCH  has  located  space  within  the  MHH  emergency  room  area  for  placement  of  the  doctor’s 
station  for  die  Digital  EMS  system.  UTHSCH  has  a  basic  plan  for  calling  the  supervising 
physicians  to  the  Digital  EMS  workstation  to  supervise  and  coordinate  care  from  an  in-route 
rural  ambulance. 

UTHSCH  identified  the  hardware  and  met  with  the  MHH  decision  makers  to  authorize 
access  to  the  network  in  order  to  create  the  network  link  between  MHH  and  the  Digital  EMS 
project.  As  reported  previously,  significant  concerns  were  brought  to  our  attention  by  the  MHH 
legal  team.  With  continuing  delays  to  security  and  privacy  as  a  part  of  the  HIPAA  regulations, 
this  goal  is  taking  longer  than  anticipated  to  complete.  In  the  next  quarter,  Dr.  James  Duke  plans 
to  meet  with  MHH  representatives  to  define  the  link  between  the  facility  and  Digital  EMS  and  to 
further  define  how  the  Digital  EMS  system  will  work  within  the  MHH  network. 

In  support  of  this  effort,  UTHSCH  has  begun  the  development  of  a  standardized  notification 
engine  to  be  used  to  alert  the  physicians  at  MHH  when  a  field  medic  requests  assistance. 
Ms.  Mekala  and  Dr.  Matthew  Sailors  have  been  drawing  up  functional  requirements  for  the 
notification  system.  As  part  of  this  effort,  Ms.  Mekala  has  conducted  an  analysis  of  the  Jabber 
platform  as  a  potential  basis  for  this  system.  Her  analysis  is  attached  as  Appendix  7. 

h.  Develop  and  Test  a  Prototype  Digital  EMS  Vehicle  in  Diverse  Urban  and  Rural 
Settings  for  Evaluation  and  Performance  Analysis  of  Integrated  Digital  Technologies.  UTHSCH 
and  TAMUS  staff  developed  a  detailed  plan  for  the  deployment  in  Liberty  County,  Texas.  Plans 
for  a  civilian  prototype  have  been  finalized  and  are  moving  forward  at  this  time.  UTHSCH  will 
execute  these  plans  in  collaboration  with  TAMUS  during  the  next  quarter  of  the  project. 

Work  to  complete  human  testing  approvals  for  volunteer  subjects  was  completed  and 
submitted  to  the  USAMRMC  IRB  at  the  end  of  2002.  Consent  documentation  was  finalized 
between  the  UTSCHS  and  TAMUS  IRB  along  with  supporting  documentation  required  by 
USAMRMC.  Once  approved,  volunteer  testing  in  Liberty  County  will  move  forward  in  first 
quarter  2003.  UTHSCH  continues  to  complete  the  State  of  Texas  community  consent 
requirements  leading  to  approval  for  human  subjects  testing  without  informed  consent  in  the 
cases  of  real  ambulance  trauma  runs.  Specific  waiver  of  10  USC  980  will  be  needed  from  the 
Department  of  the  Army  Surgeon  General  to  allow  this  project  to  follow  accepted  Texas 
guidelines. 

i.  Evaluation  of  Life  Flight  Patient  Population  to  Determine  Additional  Medical 
Functionality  Needs.  The  additional  medical  functionality  added  to  MHH  Life  Flight  vehicles 
has  not  been  fully  identified.  During  this  project  period,  UTHSCH  personnel  met  with  Life 
Flight  for  initial  meetings  for  scope  of  our  project  in  Life  Flight’s  operations.  During  the 
beginning  of  the  next  year,  the  feasibility  study  is  scheduled  to  begin. 
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While  waiting  for  the  feasibility  work  to  begin,  the  Digital  EMS  project  looked  to  a  peer’s 
interest  in  a  novel  study  on  pre-hospital  data.  Entitled  “UT-Capture  and  Analysis  of 
Physiological  Data  for  Prediction  of  Life  Threatening  Conditions  in  Trauma  Injuries,”  and 
headed  by  John  Holcombe,  MD,  this  work  captured  all  data  from  the  Lifepaq  physiological 
monitor  earned  on  the  Life  Flight  helicopters.  Once  loaded  into  the  flash  memory  of  a  personal 
data  assistant  (PDA),  a  research  nurse  loaded  the  patient  data  into  a  database  without  patient 
identifiers. 

A  Web-enabled  database  system  went  fully  online  on  June  2,  2002  (hosted  at 
http://traumavitals.tamu.edu)  and  currently  maintains  600  records  including  patient  history, 
lifesaving  interventions,  and  vital  signs  (if  available).  The  trauma  vitals  team  implemented  an 
initial  database-querying  engine  in  August  2002,  with  die  ability  to  query  the  underlying 
database  for  patients  based  on  selection  criteria.  The  system  could  then  export  results  to  a  XML 
file  on  local  machine  through  a  data  viewer/editor  finalized  completed  in  November  2002.  The 
database  also  allows  for  the  import  and  export  of  XML  waveform/numeric  information  for  post 
processing  editing  and  modification. 

This  part  of  the  Digital  EMS  project  has  been  very  successful,  and  has  already  generated 
research  interests.  Currently  there  is  a  team  of  physicians  using  the  retrospective  research 
database  for  their  own  studies  scheduled  for  completion  in  the  next  year. 

j.  Study  and  Facilitate  Integration  of  Existing  Emergency  Medical  Records  Databases. 
UTHSCH  personnel  participated  in  HL7  meetings  in  this  quarter  and  focused  in  part  on  the 
application  of  advanced  technology  in  medical  records  or  hospital  database  systems.  In  the 
changing  environments  since  HIPAA,  security  and  privacy  of  medical  data  could  not  be  over 
emphasized.  UTHSCH  met  with  authorities  at  MHH  to  plan  for  the  integration  of  the  Digital 
EMS  systems  into  the  existing  pre-hospital  medical  records  system.  The  initial  meeting  did  not 
resolve  many  issues  related  to  the  access  and  security  of  these  data.  Initially,  data  will  only  flow 
from  the  Digital  EMS  systems  into  the  MHH  clinical  data  repository  using  the  same  HL7- 
message-based  pathways  as  other  external  data  sources  (such  as  outside  laboratory  results). 
Negotiations  to  access  a  constrained,  emergency-medicine  specific  data  set  are  still  ongoing. 

k.  Develop  Methodologies  for  Using  New  Local,  State,  and  National  Network 
Infrastructures  for  Providing  the  Digital  EMS  Vehicles  with  High  Speed  Terrestrial  Connectivity 
to  the  Hospital  Nodes.  UTHSCH  personnel  participated  in  HL7  and  AMIA  meetings  in  the  past 
year.  Each  conference  focused  in  part  on  the  application  of  advanced  technology  in  medical 
records  or  hospital  database  systems. 

The  effects  of  HIPAA  security  and  privacy  constraints  on  these  networks  are  still  being 
considered.  UTHSCH  plans  careful  steps  related  to  the  medical  data  in  item  11  (j)  above.  This 
data  will  ride  not  only  on  the  local  networks  at  MHH,  but  also  on  distributed  state  and  national 
networks.  HIPAA  compliance  remains  a  significant  challenge,  and  one  that  UTHSCH  and 
TAMUS  staff  continues  to  address. 

l.  Participate  in  Military  Tests,  Evaluations,  and  Exercises.  UTHSCH  personnel  await 
notification  from  USAMRMC  for  a  venue  for  military  testing  of  the  Digital  EMS  system. 
UTHSCH  plans  to  participate  in  the  planning  and  execution  of  the  military  tests  of  the  Digital 
EMS  systems  and  will  travel  and  participate,  where  possible,  as  requested  by  USAMRMC. 

UTHSCH  is  participating  an  Integrated  Product  Team  (IFT)  tasked  to  establish 
specifications  for  a  military  prototype.  The  IPT,  under  the  direction  of  Ms.  Cheryl  Merritt, 
USAMRMC,  will  plan  the  testing  and  evaluation  of  this  prototype  during  the  coming  year.  The 
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United  States  Marine  Corps  expressed  the  most  interest  and  will  probably  be  the  first  ones  to  use 
a  military  prototype.  The  schedule  and  locations  of  the  exercises  are  still  to  be  specified,  but 
UTHSCH  is  ready  to  fully  support  the  IPT. 


m.  Evaluate  and  Pursue  Opportunities  to  Develop  and  Implement  the  Digital  EMS  System 
in  Disaster  Response  Scenarios.  UTHSCH  personnel,  in  partnership  with  TAMUS,  will  identify 
opportunities  to  transfer  lessons  learned  and  technologies  developed  to  enhance  disaster  response 
and  preparedness.  With  the  action  of  the  newly  created  Defense  of  Houston  group  locally. 
Digital  EMS  is  tracking  the  issue  of  disaster  preparedness  in  the  local  area  as  well  as  nationally. 
This  work  will  continue  in  the  next  year. 

n.  Publish  Findings  and  Results  in  Appropriate  Conference  Proceedings  and  Journals 
and  Demonstrate  Capabilities  of  the  Digital  EMS  Ambulance.  Publications  are  listed  in  the 
“Reportable  Outcomes”  section  of  this  report. 

o.  Provide  Project  Progress  Reports.  Included  in  text  form  in  this  document. 
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KEY  RESEARCH  ACCOMPLISHMENTS 


The  University  of  Texas  School  of  Health  Information  Sciences: 

•  Performed  a  comprehensive  usability  evaluation  of  Digital  EMS  Version  1 .0. 

•  Performed  a  preliminary  usability  evaluation  of  Digital  EMS  Version  2  Mockup 

•  Performed  a  task  analysis  of  Digital  EMS  Version  2  Mockup 

•  Performed  a  document  analysis  of  emergency  medicine  as  related  to  Dreams  Project. 

UT  Digital  EMS  project  staff: 

•  Leadership  in  standardizing  medical  knowledge  base  representations 

•  Development  of  XML  schemas  for  clinical  expression  language 

•  Development  of  local  XML  standard  for  representing  algorithms  (to  be  used  in  decision 
tree  versions  of  DEMS  EMT  protocols), 

•  Refinement  of  LCEMS  protocols  to  remove  ambiguity  and  ready  them  for  decision  tree 
and  computer-execution  engine  (final  versions  will  not  be  generated  until  execution 
engine  has  been  decided  on) 

•  Development  of  pre-hospital  /  emergent  clinical  concepts  data  dictionary 

•  Development  of  information  model  for  representing  pre-hospital  /  ED  clinical  encounters 

•  Analysis  of  Jabber  messaging  protocol  /  server  for  possible  use  by  DEMS. 

•  Requirements  study  and  development  of  initial  requirements  documents  for  a  notifier 
component. 

•  Design  and  preliminary  development  of  critical  care  nutrition  assistant. 

•  Initial  standardization  /  logic  refinement  of  LCEMS  protocols  (old  protocols) 

•  Survey  documenting  state  of  the  science  of  pre-hospital  clinical  care  algorithms 

•  Standardization  of  formatting  for  LCEMS  protocols  (new  protocols)  and  translation  of 
LCEMS  protocols  into  form  displayable  on  DEMS  computer  systems. 

•  Work  on  developing  XML  schema  to  represent  clinical  decision  support  knowledge 
bases.  Based  on  published  ANSI-/ISO-recognized  standards. 

•  Development  of  generic  decision  support  system  message  XML  schema  for  consideration 
by  DEMS  and  Clinical  Decision  Support  Technical  Committee  (CDSTC)  of  Health  Level 
Seven,  Inc.  (HL7)  Schema  refined  from  draft  proposal  submitted  to  CDSTC  in  2000. 

The  University  of  Texas  Health  Science  Center  at  Houston  Trauma  Vitals  Subproject: 

Design  and  implement  a  system  capable  of  the  following: 

•  Capture  a  trauma  patients  critical  vital  signs  from  incident  pickup  until  delivery  to 
hospital 

•  Merge  and  correlate  hospital  information  and  captured  data 

•  Provide  a  research  system  for  extracting  data  relationships 

•  Web  accessible  to  researchers 

•  Provide  a  basis  for  trauma  patient  injury  and  research, 

•  Web  enabled  database  system  went  fully  on  line  6/02. 

o  http://traumavitals.tamu.edu 

o  Currently  maintains  >  500  patients  including  patient  history,  life  saving 
interventions,  and  vital  signs  (if  available). 

•  Database  querying  engine  implemented  8/02 
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o  Ability  to  query  the  underlying  database  for  patients  based  on  selection  criteria, 
o  Export  to  XML  file  on  local  machine 

•  Data  viewer/editor  finalized  on  1 1/02 

o  Imports/Export  XML  waveform/numeric  information  for  post  processing  editing 
and  modification. 

Naval  Research  Laboratory  Satellite  Development: 

•  Build  Very  Small  Aperture  Terminal  (VSAT)  -  60  cm  antenna,  transmit  PA  =  80  watts. 

•  DSSS  waveform  for  transmit,  conventional  narrowband  receive. 

•  Modify  tracking  hardware  and  software  for  ambulance  use,  which  required  numerous 
terminal  retrofits  due  to  gyro  problems. 

•  Verify  and  characterize  VSAT  operation  under  motion. 

•  Motion  study  started  on  HMMWV,  replicated  on  ambulance  in  2002 

•  Feedback  provided  to  terminal  vendor  for  improvements  in  Fall  2002 
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REPORTABLE  OUTCOMES 


Abstracts  and  Posters: 

Jiajie  Zhang,  Todd  R.  Johnson,  Zhihua  Tang,  Elmer  Bemstam,  Matt  Sailors,  and  Douglas 
Tindall.  Usability  evaluation  of  a  digital  medical  information  system.  Poster  presented  at  UT 
Houston  2002  Research  Day,  Houston,  Texas,  University  of  Texas  Health  Science  Center  at 
Houston,  November  1, 2002, 

Tindall,  R.  Douglas,  Casscells,  S.  Ward,  Sailors,  R.  Matthew,  Bemstam,  Elmer  V.,  Galloway, 
Carolyn  S.,  and  Dukes,  James  H.  Saving  Lives  in  Real-Time:  A  Pre-Hospital  Telementoring 
Case.  Poster  presented  at  the  American  Medical  Informatics  Association  (AMIA)  2002 
Symposium,  San  Antonio,  TX,  November  1 1, 2002.  See  Appendix  7. 

Mekala,  V.  Master  of  Science  in  Health  Informatics,  The  University  of  Texas  Health  Science 
Center  at  Houston,  Spring  Semester  2002.  State  of  the  Science  Paper:  Computerization  Of 
Clinical  Practice  Guidelines  -  A  Review  On  Clinical  Care  Algorithm. 

Sailors,  RM,  A  Proposed  Classification  Scheme  for  Multi-Step  Clinical  Care  Algorithms, 
Journal  of  the  American  Medical  Informatics  Association.  8(Symposium  Supplement):  1015 
2001.  See  Appendix  8. 

Sailors,  RM:  ArdenML:  The  Arden  Syntax  Markup  Language  (or  Arden  Syntax:  It’s  Not  Just 
Text  Any  More!).  Journal  of  the  American  Medical  Informatics  Association.  8(Symposium 
Supplement):  1016,2001.  See  Appendix  9. 


Conferences: 

Participation  in  the  2002  American  Telemedicine  Association  annual  conference  help  in  Los 
Angeles,  California.  June  1-6, 2002. 

Participation  in  the  2002  Texas  EMS  Conference  in  Austin,  Texas.  November  24-27, 2002. 
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CONCLUSIONS 


Work  completed  in  past  year: 

Trauma  vitals  subproject: 

A  web  enabled  database  system  went  fully  on  line  6/02,  (hosted  at; 
http://traumavitals.tamu.edu)  and  currently  maintains  greater  than  600  patients  including  patient 
history,  life  saving  interventions,  and  vital  signs  (if  available).  The  trauma  vitals  team 
implemented  an  initial  database-querying  engine  in  August  of  2002  with  the  ability  to  query  the 
underlying  database  for  patients  based  on  selection  criteria.  The  system  could  then  export  results 
to  a  XML  file  on  local  machine  through  a  data  viewer/editor  finalized  completed  in  November 
2002,  The  database  also  allows  for  the  import  and  export  of  XML  waveform/numeric 
information  for  post  processing  editing  and  modification. 

This  part  of  the  Digital  EMS  project  has  been  very  successful,  and  has  already  generated 
research  interests.  Currently  there  is  a  team  of  physicians  using  the  retrospective  research 
database  for  their  own  studies  scheduled  for  completion  in  the  next  year. 


Informatics  and  data  modeling 

During  2002  the  UTHSCH  informatics  team  has  been  heavily  involved  in  the 
development  of  XML-based  representations  of  clinical  knowledge  bases  and  the  elemental 
expressions  (algebraic  manipulations)  used  in  these  knowledge  bases.  While  many  of  these 
representations  will  remain  strictly  internal  standards,  several  have  been  presented  to  standards 
development  organizations  for  consideration  as  formal,  open  standards.  Additional  work  on 
standards  on  standardized  decision  support  system  output  message  formats  and  notification 
components  has  taken  place.  The  informatics  team  has  also  developed  information  models  for 
representing  pre-hospital  and  emergent  clinical  care  encounters  and  an  associated  concept  data 
dictionary.  The  information  models  and  data  dictionary1  have  been  reconciled  with  an 
implementation  plan  developed  by  TAMUS. 

The  clinical  protocols  that  were  originally  developed  by  our  partner  EMS  provider  have 
been  logically  refined  and  prepared  for  clinical  use  as  an  online  reference  source.  Our  EMS 
provider  partner  has  asked  that  we  provide  only  this  functionality  in  the  initial  release  of  the 
protocols.  Two  competing  formats  for  representing  these  protocols  as  decision  trees  have  also 
been  developed.  An  analysis  of  these  formats  and  comparison  with  recently  published  formats 
has  not  yet  be  completed. 

Local  human  subjects  approval  for  healthy,  normal  volunteers  has  been  obtained  from 
both  UTHSCH  and  TAUMS,  Submission  for  USA  approval  has  occurred. 


A  data  dictionary  is  a  set  of  tables  that  list  concept  names,  definitions,  references  to  standardized 
terminologies,  and  where  appropriate  the  enumerated  list  of  values  that  a  concept  may  hold,  e.g.  patient 
sex  can  be  male  or  female.  Data  dictionaries  DO  NOT  address  how  data  is  organized  in  any  given 
instantiation,  e.g.  a  database  or  encrypted  table,  nor  do  they  explicitly  endorse  any  specific  information 
model;  they  only  bound  the  content  space. 


16 


Digital  EMS  vehicle  procurement: 

During  the  past  year,  UTHSCH  completed  the  process  for  the  procurement  of  two 
additional  Digital  EMS  vehicles.  The  digital  EMS  team  issued  requests  for  proposals  and 
quotations  were  received.  The  actual  contracts  for  the  execution  of  these  orders  are  still  being 
negotiated,  anticipating  construction  to  begin  in  the  first  quarter  of  2003 . 

UTHSCH  and  TAMUS  Digital  EMS  teams  are  writing  testing  and  training  plans  for  the 
field-testing  of  these  vehicles  in  Liberty,  Brazos,  and  Webb  counties  within  Texas.  The  goal  of 
this  testing  is  to  operate  the  vehicles  in  remote  areas  with  different  terrain  environments  and  with 
different  EMS  services.  Once  this  is  completed,  retrospective  study  can  be  done  on  the  research 
databases  built  with  prehospital  patient  data. 

Work  to  be  completed  In  next  year:  ■> 

The  principal  trauma  vitals  subproject  goals  for  2003  are: 

•  Make  sensor  inputs  more  effective. 

•  Automate  data  clean  up  at  capture  or  post  processing  time  —  need  subject  matter  expert. 

•  Miniaturize  and  increase  the  ruggedness  of  data  collection  system. 

•  Establish  more  effective  management  of  large  datasets. 

•  Querying  engine  for  continuous  (and  semi  discreet)  data. 

•  Data  mining  of  real  time  data. 

The  principal  informatics  and  data  modeling  goals  for  2003  are: 

•  completion  of  the  decision  tree  representation  of  the  EMS  protocols. 

•  final  adoption  of  computer-interpretable  guideline  format(s). 

•  representation  of  EMS  protocols  in  computer-interpretable  format(s). 

•  negotiation  of  a  data  transfer  format  and  data  set  with  partner  hospital. 

•  adoption  /  development  of  computerized  decision  support  system  engine. 

•  continued  work  with  standards  development  organization  to  promote  DEMS-developed 
tools  and  methods  as  formal  standards. 

•  USA  and  local  IRB  approvals  to  allow  use  of  DEMS  with  actual  patients  in  communities. 

The  principal  Digital  EMS  vehicle  procurement  and  field-testing  goals  for  2003  are: 

•  Completion  of  the  two  Digital  EMS  ambulances, 

o  Implement  the  revised  Digital  EMS  onboard  software  as  developed  by  TAMUS. 
o  Test  the  new  software  and  hardware  with  the  SHIS  evaluation  team. 

•  Train  physicians  and  EMTs  on  the  Digital  EMS  system  in  the  IBT  test  bed. 

•  Support  the  field-testing  of  the  ambulances  in  Liberty  and  subsequent  counties. 

•  Establish  the  research  prehospital  database  for  retrospective  study. 

•  Install  and  field-test  the  mobile  satellite  terminal  system  developed  by  the  Naval 
Research  Laboratory 
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0.  INTRODUCTION 


A  complete  usability  engineering  project  of  Digital  EMS  includes  four  major  components:  user, 
functional,  task,  and  representational  analyses  (see  Figure  0).  Heuristic  evaluation,  which  is 
reported  in  this  document,  is  at  the  level  of  representational  analysis  and  it  is  one  of  the  major 
techniques  at  this  level.  In  this  introduction  section  (Section  0)  we  briefly  introduce  these  four 
analyses.  In  Sections  1,2,  and  3  that  follow,  we  will  report  the  results  of  a  heuristic  evaluation  of 
Digital  EMS.  It  should  be  noted  that  a  heuristic  evaluation  identifies  only  potential  usability 
problems  in  the  existing  interface.  It  does  not  indicate  the  elements  of  the  system  that  correctly 
follow  usability  guidelines.  Nor  does  it  reveal  major  missing  functionality.  Other  usability 
engineering  techniques  at  the  levels  of  functional  analysis,  user  analyses  can  indicate  what  is 
right  with  the  system  and  identify  the  most  appropriate  functionality. 

User  analysis  is  the  process  of  identifying  the  characteristics  of  existing  and  potential  users,  such 
as  expertise  and  skills,  knowledge  bases,  education  background,  cognitive  capacities  and 
limitations,  perceptual  variations,  age  related  skills,  cultural  background,  personality,  time 
available  for  learning  and  training,  frequency  of  system  use,  etc.  User  analysis  can  help  us  design 
systems  that  have  the  right  knowledge  and  information  structure  that  match  that  of  the  users.  For 
a  distributed  human-computer  systems,  it  is  critical  to  analyze  the  group  properties  of  users,  such 
as  division  of  cognition  and  activity,  overlap  of  knowledge  and  skills,  communication  channels 
and  styles,  social  status,  and  so  on. 

Functional  analysis  is  the  process  of  identifying  critical  top-level  domain  structures,  goals,  and 
ideal  spaces  that  are  largely  independent  of  implementations.  It  is  more  abstract  than  task  and 
representational  analyses  because  it  does  not  involve  details  of  task  processes  and  representation 
details. 

Task  analysis  is  the  process  of  identifying  system  functions  that  have  to  be  performed, 
procedures  and  actions  to  be  carried  out  to  achieve  task  goals,  information  to  be  processed,  input 
and  output  formats  that  are  required,  constraints  that  must  be  considered,  communication  needs 
that  have  to  be  satisfied,  and  the  organization  and  structure  as  well  as  the  information  categories 
and  information  flow  of  the  task.  One  important  function  of  task  analysis  is  to  ensure  that  only 
the  necessary  and  sufficient  task  features  that  match  users'  capacities  and  are  required  by  the  task 
will  be  included  in  system  implementations.  Extra  fancy  features  and  features  that  do  not  match 
users'  capacities  or  not  required  by  the  task  will  only  generate  extra  processing  demands  for  the 
user  and  thus  make  the  system  harder  to  use. 

Functional  and  task  analyses  are  concerned  with  the  functions,  structures,  and  processes  of 
systems.  The  interface  between  systems  and  users  is  handled  by  representational  analysis. 
Representational  analysis  is  the  process  of  identifying  an  appropriate  information  display  format 
for  a  given  task  performed  by  a  specific  type  of  users  such  that  the  interaction  between  users  and 
systems  is  in  a  direct  interaction  mode.  With  direct  interaction  interfaces,  users  can  directly, 
completely,  and  efficiently  engage  in  the  primary  tasks  they  intend  to  perform,  not  the 
housekeeping  interface  tasks  that  are  barriers  between  users  and  systems. 
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Figure  0.  A  typical  usability  engineering  project  involves  user,  functional,  task,  anJ0efCeptU£ 
representational  analyses.  Heuristic  evaluation ,  which  is  reported  in  this  document,  is  at  the 
level  of  representational  analysis  and  it  is  one  of  the  major  techniques  at  this  level. 
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EXECUTIVE  SUMMARY 


The  following  report  gives  the  results  of  the  heuristic  evaluation  of  Digital  EMR  Version  1.0.  It 
is  important  to  realize  that  a  heuristic  evaluation  identifies  only  potential  usability  problems  in 
the  existing  interface.  It  does  not  indicate  the  elements  of  the  system  that  correctly  follow 
usability  guidelines.  Nor  does  it  reveal  major  missing  functionality.  Other  usability  engineering 
techniques,  such  as  functional  analysis,  user  analysis,  and  task  analyses  can  indicate  what  is  right 
with  the  system  and  identify  the  most  appropriate  functionality. 

The  14  usability  heuristics  used  for  evaluations  were  violated  161  times  (all  three  workstations 
combined).  Visibility  and  Consistency  are  die  two  heuristics  with  most  violations  (48  and  29, 
respectively).  The  next  one  is  Match  with  22  violations.  Note  that  the  Protocol  function  in 
Digital  EMS  has  not  been  thoroughly  evaluated  in  the  current  study  because  it  is  not  fully 
implemented  yet. 

There  are  6  catastrophic  violations  that  received  severity  ratings  over  3.50.  It  is  imperative  to  fix 
them.  48  violations  are  major  violations  (severity  ratings  between  2.50  and  3,50)  that  are 
important  to  fix  and  should  be  given  high  priority.  27  violations  are  minor  violations  (between 
1.50  and  2.50)  that  have  low  priority  in  fixing.  And  there  is  1  cosmetic  problem  that  needs  not  be 
fixed  unless  extra  time  is  available. 

The  Paramedic’s  Station  has  the  largest  number  of  violations  (45).  Note  that  this  number  does 
not  take  into  account  the  Protocol  function.  The  numbers  of  violations  identified  on  the 
Physician’s  and  Driver’s  Workstations  are  19  and  18,  respectively.  The  average  severity  ratings 
of  all  three  workstations  are  over  2,50,  indicating  that  these  are  major  usability  problems  that 
should  be  fixed  with  high  priority. 

For  every  heuristic  violation,  we  recommended  a  potential  solution.  Tables  1. 1-1.3  and  2.1-2.3 
show  the  details  of  the  violations  and  recommended  solutions. 


2.  METHODOLOGY 

The  heuristics  evaluation  methodology  adopted  here  is  a  discount  usability  technique  that  is  used 
to  identify  the  major  usability  problems  of  a  product  in  a  timely  manner  with  reasonable  cost. 
This  technique  requires  three  or  more  usability  experts  to  independently  apply  a  set  of  usability 
heuristics  to  a  product,  identify  violations  of  the  heuristics,  and  assess  the  severity  of  each 
violation. 

The  three  usability  experts  (evaluators)  for  the  evaluation  of  Digital  EMS  are  Dr.  Jiajie  Zhang, 
Dr.  Todd  R.  Johnson,  and  Ms.  Zhihua  Tang.  They  evaluated  the  user  interface  and  generated  a 
list  of  heuristics  violations  according  to  the  fourteen  heuristics  described  below.  This  list  was 
given  to  the  three  evaluators  who  then  independently  accessed  the  severity  of  each  violation.  The 
ratings  from  the  three  evaluators  were  averaged.  The  averaged  ratings  are  reported.  The  next  two 
sections  describe  the  usability  heuristics  used  for  Digital  EMS  and  the  scale  of  the  severity 
rating. 
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2.1  Usability  Heuristics 

The  following  fourteen  heuristics  were  developed  by  Jiajie  Zhang  and  Todd  R.  Johnson.  The 
words  in  the  brackets  are  the  semantic  tags  for  the  heuristics. 

1.  [Consistency]  Consistency  and  Standards.  Users  should  not  have  to  wonder  whether 
different  words,  situations,  or  actions  mean  the  same  thing.  Standards  and  conventions  in 
web  design  should  be  followed. 

a.  Sequences  of  actions  (skill  acquisition) 

b.  Color  (categorization) 

c.  Layout  and  position  (spatial  consistency) 

d.  Font,  capitalization  (levels  of  organization) 

e.  Terminology  (delete,  del,  remove,  rm)  and  language  (words,  phrases) 

f.  Standards  (e.g. ,  blue  underlined  text  for  unvisited  hyperlinks) 

2.  [Visibility]  Visibility  of  System  State.  Users  should  be  always  informed  what  is  going 
on  with  the  system  through  appropriate  feedback  and  display  of  information. 

a.  What  is  the  current  state  of  the  system? 

b.  What  can  be  done  at  current  state? 

c.  Where  can  users  do? 

d.  What  change  is  made  after  an  action? 

3.  [Match]  Match  between  System  and  World.  The  image  of  the  system  perceived  by 
users  should  match  the  model  the  users  have  about  the  system. 

a.  User  model  matches  system  image 

b.  Actions  provided  by  the  system  should  match  actions  performed  by  users 

c.  Objects  on  the  system  should  match  objects  of  the  task 

4.  [Minimalist]  Minimalist,  Any  extraneous  information  is  a  distraction  and  a  slow-down. 

a.  Less  is  more 

b.  Simple  is  not  equivalent  to  abstract  and  general 

c.  Simple  is  efficient 

d.  Progressive  levels  of  detail 

5.  [Memory]  Minimize  Memory  Load.  Users  should  not  be  required  to  memorize  a  lot  of 
information  to  carry  out  tasks.  Memory  load  reduces  users’  capacity  to  carry  out  the  main 
tasks. 

a.  Recognition  vs.  recall  (e.g.,  menu  vs.  commands) 

b.  Externalize  information  through  visualization 

c.  Perceptual  procedures 

d.  Hierarchical  structure 

e.  Default  values 

f.  Concrete  examples  (DD/MM/YY,  e.g.,  10/20/99) 

g.  Generic  rules  and  actions  (e.g.,  drag  objects) 
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6.  [Feedback]  Informative  Feedback,  Users  should  be  given  prompt  and  informative 
feedback  about  their  actions, 

a.  Direct  perception  (7  stage  model) 

b.  Information  that  can  be  directly  perceived  and  inteipreted, 

c.  Levels  of  feedback  (novice  and  expert) 

d.  Concrete  and  specific,  not  abstract  and  general, 

e.  Response  time 

•  0,1  second  for  instantaneously  reacting 

•  1.0  second  for  uninterrupted  flow  of  though 

•  10  seconds  for  the  limit  of  attention 

7-  [Flexibility]  Flexibility  and  efficiency.  Users  always  learn  and  users  are  always 
different.  Give  users  the  flexibility  of  creating  customization  and  shortcuts  to  accelerate 
their  performance. 

a.  Shortcuts  for  experienced  users 

b.  Shortcuts  or  macros  for  frequently  used  operations 

c.  Skill  acquisition  through  chunking 

d.  Examples: 

•  Abbreviations,  function  keys,  hot  keys,  command  keys,  macros,  aliases, 
templates,  type-ahead,  bookmarks,  hot  links,  history,  default  values,  etc. 

8.  [Message]  Good  Error  Messages.  The  messages  should  be  informative  enough  such  that 
users  can  understand  the  nature  of  errors,  learn  from  errors,  and  recover  from  errors. 

a.  Phrased  in  clear  language,  avoid  obscure  codes 

•  e.g.,  “system  crashed,  error  code  147” 

b.  Precise,  not  vague  or  general, 

•  e.g,,  “Cannot  open  document” 

c.  Constructive 

d.  Polite 

•  e.g.,  “illegal  user  action”,  “job  aborted”,  “system  was  crashed”,  “fatal 
error”,  etc. 

9.  [Error]  Prevent  Errors.  It  is  always  better  to  design  interfaces  that  prevent  errors  from 
happening  in  the  first  place. 

a.  Interfaces  that  make  errors  impossible, 

b.  Avoid  modes  (e.g.,  vi,  text  wrap,).  Or  use  informative  feedback,  e.g.,  different 
sounds. 

c.  Execution  error  vs.  evaluation  error 

d.  Various  types  of  slips, 

10.  [Closure]  Clear  Closure.  Every  task  has  a  beginning  and  an  end.  Users  should  be  clearly 
notified  about  the  completion  of  a  task. 

a.  Clear  beginning,  middle,  and  end. 

b.  Complete  7-stages  of  actions. 

c.  Clear  feedback  to  indicate  goals  are  achieved  and  current  stacks  of  goals  can  be 
released. 
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e.g.,  dialogues. 


11.  [Undo]  Reversible  Actions.  Users  should  be  allowed  to  recover  from  errors.  Reversible 
actions  also  encourage  exploratory  learning. 

a.  At  different  levels:  a  single  action,  a  subtask,  or  a  complete  task 

b.  Multiple  steps 

c.  Encourage  exploratory  learning 

d.  Prevent  serious  errors 

12.  [Language]  Use  Users’  Language.  The  language  should  be  always  presented  in  a  form 
understandable  by  the  intended  users. 

a.  Use  standard  meanings  of  words 

b.  Specialized  language  for  specialized  group 

c.  User  defined  aliases 

d.  Users’  perspective 

•  e.g.,  “we  have  bought  four  tickets  for  you”  vs.  “you  bought  four  tickets” 

13.  [Control]  Users  in  Control.  Don’t  give  users  that  impression  that  they  are  controlled  by 
the  systems. 

a.  Users  are  initiators  of  actors,  not  responders  to  actions. 

b.  Avoid  surprising  actions,  unexpected  outcomes,  tedious  sequences  of  actions,  etc. 

14.  [Document]  Help  and  Documentation.  Always  provide  help  when  needed. 

a.  Context-sensitive  help 

b.  Four  types  of  help 

•  task-oriented 

•  alphabetically  ordered 

•  semantically  organized 

•  search 

c.  Help  embedded  in  contents 

2.2  Severity  Rating  Scale 

The  following  scale  is  used  for  the  assessment  of  the  severity  of  each  heuristic  violation. 

0  =  1  don't  agree  that  this  is  a  usability  problem  at  all 

1  =  Cosmetic  problem  only:  need  not  be  fixed  unless  extra  time  is  available  onproject 

2  =  Minor  usability  problem:  fixing  this  should  be  given  low  priority 

3  =  Major  usability  problem:  important  to  fix,  so  should  be  given  high  priority 

4  =  Usability  catastrophe:  imperative  to  fix  this  before  product  can  be  released 

As  a  guideline  for  rating  the  problems,  we  consider  the  proportion  of  users  who  will  experience 
it,  the  impact  it  will  have  on  their  experience  with  the  product,  and  whether  the  usability  problem 
will  be  a  problem  only  the  first  time  they  encounter  it,  or  whether  it  will  persistently  bother  them. 
A  persistent  problem  with  a  major  impact  that  most  users  will  encounter  will  get  the  highest 
severity  rating. 
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3.  RESULTS 


Figures  1, 2,  and  3  show  the  heuristics  violations  in  Digital  EMR  along  different  dimensions.  See 
the  figure  captions  for  explanations.  Tables  1.1  -1.3  show  details  of  the  violations  ordered  by 
places  of  occurrences  for  the  Paramedic’s  Station,  Physician  Station,  and  Driver’s  Station. 
Tables  2.1 -2.3  show  them  sorted  by  severity  ratings.  Potential  solutions  were  recommended  for 
all  the  violations  in  the  tables. 


Heuristics  Categories 


Figure  1.  The  14  usability  heuristics  used  for  evaluations  were  violated  161  times  (all  three 
workstations  combined.)  Visibility  and  Consistency  are  the  two  heuristics  with  most  violations 
(48  and  29,  respectively).  The  next  one  is  Match  with  22  violations.  Note  that  the  Protocol 
function  has  not  been  thoroughly  evaluated  in  the  current  study  because  it  is  not  fully 
implemented. 
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Severity  Rating 


Figure  2.  There  are  6  catastrophic  violations  that  received  severity  ratings  over  3.50.  It  is 
imperative  to  fix  them.  48  violations  are  major  violations  (severity  ratings  between  2.50  and 
3.50)  that  are  important  to  fix  and  should  be  given  high  priority.  27  violations  are  minor 
violations  (between  1.50  and  2.50)  that  have  low  priority  in  fixing.  And  there  is  1  cosmetic 
problem  that  needs  not  be  fixed  unless  extra  time  is  available. 
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Frequencies  and  Severity  Ratings  by  Workstation 


Paramedic's  station  Physician’s  station  Driver's  station 


Figure  3.  The  paramedic’s  station  has  the  largest  number  of  violations  (45).  Note  that  this 
number  does  not  take  into  account  the  protocol  function.  The  numbers  of  violations  identified  on 
the  physician  s  and  driver  s  workstation  are  19  and  18,  respectively.  The  average  severity  ratings 
of  all  three  workstations  are  over  2.50,  indicating  that  these  are  major  usability  problems  that 
should  be  fixed  with  high  priority. 
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Severity 


Table  1.1.  Heuristics  Violations:  by  Places  of  Occurrences 
—  Paramedic’s  Station 


Function: 

Section 

Problem  Description  (P) 

Recommended  Solution  (S) 

Heuristics 

Violated 

n a 

Overall 

P:  Function  navigation  bar  is  separated  from  section 
tabs  within  each  function.  Major  functions  are  located 
at  the  bottom  of  the  screen,  whereas  the  tabs  on  the 
top  of  the  screen  represent  lower  level  sections.  This 
makes  it  hard  to  see  the  connections  between  the  two, 
and  requires  constant  moving  (and  looking)  up  and 
down  during  navigation.  This  problem  persisted  after 
we  gained  experience  with  the  system,  indicating  that 
it  will  not  disappear  with  experience. 

S:  Move  the  function  navigation  bar  to  the  top,  above 
the  section  tabs.  Use  a  two-level  tab  navigation  bar  at 
the  top. 

Visibility 

Consistency 

Match 

Memory 

Error 

3.33 

P:  Functions  “Run  Record”  and  “Report”  have  a 
number  of  sections  that  require  the  paramedic’s  input. 

It  is  not  clear  at  all  if  clicking  button  “Save  Current 
Record”  (on  Run  Record:  On-Scene)  saves  all  the 
information  or  each  section  needs  to  be  saved 
separately. 

S:  Provide  “Save  Data”  on  each  data  entry  page.  This 
button  should  be  in  the  same  place  on  every  page.  A 
more  systematic  solution  is  to  create  a  drop-down 
menu  that  contains  all  the  major  functions  common 
for  all  sections,  such  as  the  “File”  menu  on  all 
Microsoft  products,  d. 

Visibility 

Memory 

Consistency 

Feedback 

3.67 

P:  There  is  no  visible  indication  of  whether  data  needs 
to  be  saved  or  whether  it  has  been  saved. 

S:  If  the  system  does  not  automatically  save  after 
every  entry,  provide  a  salient  indication  on  every 
screen  that  a  save  is  required.  One  way  to  do  this  is  by 
activating  and  visually  highlighting  the  Save  button 
anytime  a  save  is  required.  If  the  system  autosaves 
only  when  a  user  switches  to  a  different  page,  you 
must  still  provide  some  visible  indicator  on  each  page 
to  let  the  user  know  that  the  data  has  (or  has  not)  been 
saved;  otherwise,  the  user  will  not  know  whether  or 
not  the  data  has  been  autosaved. 

Visibility 

Feedback 

3.33 

P:  Pull-down  menus  in  data  entry  sections  also  allow 
the  paramedic  to  type  in  information  manually,  but  the 
arrow  buttons  give  the  impression  that  one  can  only 
select  from  the  menu. 

Visibility 

Consistency 

2.33 

30 


Run  Record: 
On-Scene 


S:  Emphasize  this  in  training;  Set  default  for  pull- 
down  menus  as  “type  or  select”. 


P:  Buttons  “Create  New  Record”  and  “Save  Current 
Record”  are  inconsistent  with  the  rest  of  the  buttons 
and  are  difficult  to  see. 

S:  Use  a  consistent  button  design.  Place  “create  new 
record”  and  “save  current  record”  at  the  top  of  the 
page,  separated  from  the  data  fields.  Consider  adding 
a  menu  bar  containing  one  or  more  menus  at  the  top 
for  common  and  frequent  tasks. 


P:  Patient’s  name,  currently  at  the  bottom,  is  difficult 
to  see,  both  because  of  its  font  size  and  of  its  location, 
S:  Display  patient’s  name  in  a  more  prominent 
location  (on  top,  near  the  section  tabs)  and  in  a  bigger 
font. _ 


P;  If  no  patient’s  name  is  entered,  name  field  only 
displays 

S:  The  system  should  designate  a  default  value  (e.g., 
patient  #1)  for  patients  whose  name  is  not  accessible. 


P:  Create  new  record  does  not  update  the  patient’s 
name  at  the  bottom. 

S:  default  to  “New  Patient.” 


P:  Modifying  the  first  or  last  name  creates  a 
completely  new  record. 

S:  Provide  feedback  (e.g.,  display  a  message)  prior  to 
automatically  generating  a  new  record.  This  should  be 
associated  with  the  “save”  function.  Use  “save”  to 
save  to  current  file  and  “save  as”  to  save  to  a  new  file. 
Again,  the  current  “save”  function  needs  to  be 
redesigned. _ 


P:  No  feedback  once  “Save  Current  Record”  is 
clicked. 

S:  Provide  explicit  feedback  (e.g,,  change  the  cursor, 
or  display  a  message.)  Or  completely  redesign  the 
“save”  function  such  as  move  it  to  a  top  menu. 


P:  If  a  2nd  record  arrives  (a  new  ID  is  scanned  in,)  the 
1st  record  is  gone  without  warning  the  user.  And  there 
is  no  indication  of  whether  the  old  is  saved  or  not 
saved. 

S;  Provide  explicit  feedback  (e.g.,  display  a  message.) 


P:  No  suggestion  on  re-saving  record  once  data  in  a 
section  is  modified. 

S:  If  information  in  a  section  is  changed,  before  the 
paramedic  switches  to  another  function  (section), 
display  a  message  as  a  reminder. 


P;  In  the  vehicle  pop-up  menu,  if  the  mouse  is  on  the 


Consistency 

Visibility 

Match 

Consistency 

2.33 

Visibility 

3 

Memory 

Visibility 

2.67 

Consistency 

Visibility 

Feedback 

2.67 

Consistency 

Feedback 

Error 

Match 

3.67 

Feedback 

3.33 

Error 

Visibility 

Undo 

3.67 

Visibility 

3 

Bug 

2.33 

31 


top  half  of  the  arrow  button  when  it  is  clicked,  the 
menu  won’t  stay  (hitting  “van”);  if  on  the  bottom  half, 
then  the  menu  stays; 

S:  Use  radio  buttons  or  small  graphics  to  display 
options,  instead  of  the  pop-up  menu.. 

Match 

Visibility 

P:  Scan  ID  in  to  create  a  new  record.  Once  you  click 
on  the  arrow,  the  record  is  gone. 

S:  fix  the  bug 

bug 

4 

Run  Record: 
Exam/Obser 
vation 

P:  No  way  to  change  the  image  (gender  of  the  patient) 
from  this  page,  the  user  must  return  to  the  page 
containing  demographic  data. 

S;  Set  up  two  radio  buttons  above  the  image  to  allow 
the  paramedic  to  change  the  gender. 

Control 

Flexibility 

2 

P:  The  question  mark  besides  the  Glascow  scale  is  not 
clear  in  terms  of  its  meaning.  It  should  also  be  put 
inside  the  boundary  box  surrounding  the  Glascow 
scale. 

S:  Label  the  “?”  button  in  text. 

Visibility 

Memory 

2,33 

P:  Pull-down  menu  for  consciousness  does  not  cover 
the  full  range  of  consciousness. 

S:  Add  more  options  to  make  the  list  complete. 

Match 

2.67 

P:  The  Left,  Right  Pupil  pull-down  menus  also  allow 
type-in  but  each  has  only  two  choices. 

S:  If  there  are  only  two  choices,  it  is  better  to 
implement  as  radio  buttons  or  at  least  not  allow  type- 
in. 

Visibility 

Minimalism 

2.33 

You  can  have  only  one  number  on  the  body  image, 
but  it  allows  you  to  add  more  symptom  items  (Note: 
this  may  not  be  a  usability  problem  at  all  if  it  is  ok  for 
the  paramedic  to  enter  symptoms  here  without 
specifying  where  they  are  on  the  body  image.) 

No  connections  between  the  numbers  and  the  GUI 
widgets. 

Match 

1.33 

Rim  Record: 
Patient  HX 

■Hiiiiid 

■ 

2,33 

Run  Record: 
Patient  TX 

P:  Medication  and  dosage/route  are  not  linked  (The 
latter  two  are  not  sensitive  to  the  value  in  the 
medication  slot.) 

S:  Make  the  options  for  Dosage  and  Route  contingent 
upon  input  in  the  Medicine  slot. 

Consistency 

Error 

2.67 

P:  No  indication  of  the  format  of  the  time. 

S;  Specify  the  format  of  the  time  by  giving  an 
example,  e.g.,  18:45 

Memory 

Match 

2.67 
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Video/Vital 


Protocols 


P:  The  function  of  the  set  button  following  time  is  not 
clear  at  all.  No  feedback  after  it  is  clicked.  What 
happens  if  it  is  not  clicked?  Does  it  have  to  be  clicked 
for  something  to  happen?  Can  time  still  be  changed 
after  “set”  is  clicked? 

S:  Remove  it  if  is  redundant. _ 


Pi  “Responses  to  TX”  is  separate  from  the  medication 
(listed  above.)  There  could  be  a  number  of 
medications  but  there  is  only  one  response  slot. 

Si? 


Run  Record:  Pi  The  function  of  this  section  is  not  very  clear. 
Narrative  S:  If  both  the  paramedic  and  the  physician  can 

provide  input  here,  it  needs  to  have  two  separate  fields 
for  each  party  for  synchronization  purpose. 


P:  Patient’s  name  is  not  displayed.  What  happens  if 
there  is  more  than  one  patient  on  board? 

S:  Display  patient’s  name  in  a  prominent  location 
(same  as  with  the  Run  Record  function.’) 


P:  Lots  of  problems.  It  needs  to  be  completely 
redesigned.  Just  a  few  examples  of  design  problems, 

1.  Structure  of  the  screen  protocols  appears  to  be 
hierarchical  (title  with  six  types,)  but  in  fact  they  are 
parallel; 

2.  Cursor  doesn’t  change  on  html  links; 

3.  When  deep  in  the  structure,  no  indication  of  the 
level; 

4.  On  certain  pages,  there  is  an  invisible  but 
functional  “back”  button. 

S:  This  section  needs  to  be  completely  re-designed  to 
conform  to  web  design  standards.  For  example, 

1 .  The  first  screen  should  be  called  “index”  page; 

2.  Always  provide  a  back  button  on  each  page. 


P:  Address  fields  on  the  top  allow  selection  by  mouse 
and  appear  to  be  editable,  but  the  user  is  not  allowed 
to  edit  them. 

S:  Display  the  information  as  pure  text,  not  as  a  text 
box  field. 


P:  On  the  right  panel,  Destination,  TBD,  and  Range 
are  actually  pull-down  menus  but  it  is  impossible  to 
see  this  because  of  low  contrast  (Background  of  the 
menus  is  same  as  that  for  the  whole  screen  display.) 
S:  Change  their  background  to  increase  visibilitv. 


P:  The  middle  button  of  the  keypad  has  two  modes 
(GPS  and  scroll.)  Exactly  what  does  each  mode 
mean?  Also  in  scroll  mode,  clicking  on  an  arrow 
causes  the  mid  button  to  automatically  switch  to  GPS. 


Memory  3.33 

Feedback 

Visibility 


Match 


Match 


Visibility  3.33 

Match 

Memory 
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Consistency 
Memory 
Match 
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Visibility 


Visibility  3 


Visibility  3.33 

Memory 
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Comms 


Report 


Report: 

Vitals 

Report 


Report: 

Billing 


Report: 

Release: 


S:  The  middle  button  should  not  be  used  as  a  mode 
button. 


P:  All  the  options  are  not  clickable.  Besides,  the 
option  button  is  under  ICM  but  all  the  rest  are  located 
above  their  respective  channels. 

S:  If  options  do  not  serve  any  function,  remove  them. 


P:  On  and  Off  look  like  radio-buttons,  giving  the  false 
impression  that  they  are  clickable. 

S:  If  this  information  is  redundant  with  Throughput, 
consider  removing  it  completely. 


P:  Bandwidth  is  displayed  in  numbers.  It  could  be  a 
bit  too  complicated  for  paramedics. 

S:  Could  be  better  implemented  as  graphs. 


P:  Once  you  click  on  “report”,  the  last  section  in  the 
previous  “report”  session  is  the  default.  There  is  no 
absolute  default  page  (even  across  patients.) 

S:  Set  a  default  section. _ 


P:  The  text  entered  for  one  patient  is  displayed  for 
every  patient  once  the  patient  name  is  switched.  (Is  it 
saved?  Don’t  know.) 

S:  fix  the  bug _ 


P:  Incident  does  not  tell  what  should  be  reported; 
Date:  no  format  indicated;  Dispatch  (Time):  no  format 
indicated;  when  impossible  data  are  entered,  the 
system  gives  no  error  message.  It  is  not  clear  what  the 
two  “set”  buttons  mean?  Once  clicked,  time  is  still 
editable. 

S:  use  examples  to  show  the  format.  Reconsider  die 
“set”  buttons. _ 


P:  Can’t  switch  to  another  patient  on  this  page  though 
it  seems  to  allow  this. 

S:  either  remove  the  patient  selection  drop-down 
menu  to  disallow  the  switching  of  patient  or  make  it 
switch-able.  _ 


P:  Patient  name  and  address  should  be  consistent  with 
the  information  obtained  in  other  sections. 

S:  Automatically  fill  in  the  slots  from  input  in  other 
sections. 


P:  Bill  To:  options  as  buttons 

S:  use  radio  buttons  instead  of  buttons. 


P:  Options  for  relationships  are  not  complete. 
S:  Should  include  more  choices. 


P:  Zip  code  slot  and  tel  #  slot  allow  for  text  as  input. 
S:  These  two  slots  should  allow  onlv  numbers. 


P:  Date  slots  are  not  constrained,  and  format  is  not 
specified 


Consistency 

Visibility 


Consistency 

Visibility 


Consistency 

Match 


Error 

Visibility 

Memory 


Match 


Error 


Flexibility 

Visibility 


Minimalist 
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S:  This  slot  should  only  allow  number  input  and 
format  should  be  indicated 

P:  No  way  to  input  signature. 

S:  Should  this  page  be  printed  out  and  have  patients 
sign  on  paper? 

Match 

1.67 

Report: 

Transport/C 

rew 

P:  Patient  transported  to  slot  should  read  directly  from 
map  information. 

S:  Automatically  fill  in  the  slots  from  input  in  other 
sections. 

Minimalist 

Memory 

2.33 

Report: 

Report 

P:  Ambiguous  section  meaning.  Also  print  to  a  printer 
in  the  ambulance  or  in  die  hospital? 

S;  Section  should  be  labeled  “Print”.  Also  should 
separate  “Print”  from  “Report”.  This  can  be  done  by 
adding  a  menu  bar  that  includes  save,  save  as,  print, 
exit,  etc. 

Consistency 

Match 

2.67 

P:  First  5  items  are  from  Run  Record,  the  last  4  are 
from  Report. 

S:  Should  provide  separation  between  these  two 
categories. 

Consistency 

Visibility 

2.33 

P:  What  if  there  is  more  than  one  patient?  In  Run 
record,  one  can  easily  choose  a  patient.  In  Report,  one 
can’t  do  this.  The  patient  is  set  to  whoever  is  selected 
in  run  record. 

S;  either  allow  switching  between  patients  here  or 
disallow  it  by  not  showing  the  drop-down  button. 

Flexibility 

Visibility 

2.67 

P:  Once  a  record  is  created,  everything  from  the 
previous  report  is  copied. 

S:  fix  the  bug 

bug 

4 
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Table  1,2,  Heuristics  Violations:  by  Places  of  Occurrences 


Physician’s  Station 


Function: 

Section 


Overall 


Problem  Description  (P) 
Recommended  Solution  (S 


P:  No  mdication  as  to  which  EMS  (of  multiple  ones) 
the  current  record  is  from, 

S:  Display  the  AmblD/patient’s  name  on  EACH 
function/section  page,  and  at  a  prominent  location. 


P:  How  does  the  physician  know  how  to  divide  his  or 
her  time  among  different  ambulances/patients?  The 
patient  list  does  not  provide  information  for  the 
physician  to  determine  priority. 

S:  more  information  should  be  provided  such  that  the 
ER  physicians  can  make  informed  decisions. 


P:  All  sections  within  “Run  Record”  are  much  the 
same  as  on  the  paramedic’s  station.  However,  the 
normal  text  fields  and  pull-down  menus  (though 
deactivated)  give  rise  to  the  false  impression  that  the 
physician  can  change  the  data.  There  is  no  indication 
that  they  will  never  be  active. 

S:  If  the  data  are  never  editable,  display  them  in  pure 
text  instead  of  in  text  box  fields.  If  the 
controls/buttons  can  never  be  used,  remove  them  from 
the  screen..  If  the  controls  may  sometimes  be  used, 
find  a  way  to  make  these  items  look  inactive  and  make 
sure  the  users  know  how  to  activate  them. 


Run  Record:  P:  Message  displayed  beside  the  vehicle  is 
On-Scene  inconsistent  with  the  actual  action  allowed  (the 
physician  should  not  set  anything  for  the  vehicle 
involved.) 

S:  Take  away  the  message  and  the  arrow  button  to  the 
right  of  the  vehicle  image. 


P:  The  “Refresh  Records”  button  (a  function  button) 
is  embedded  in  the  patient’s  data  and  hard  to  see.  Also 
clicking  this  button  gives  no  feedback, 

S:  Move  this  button  to  a  more  prominent  location  (at 
the  top,  near  the  section  tabs.)  Provide  visual  feedback 
(change  the  cursor  or  display  a  message)  when  the 
physician  clicks  this  button.  Or  integrate  it  into  a  top 
menu  bar  with  other  major  functions  such  as  “save”. 
Videos  P:  AmbID  is  a  pull-down  menu  but  is  hard  to  see 
because  of  low  contrast;  the  patient’s  name  is  not 
shown  here, 

S:  Change  the  background  of  the  pull-down  menu  to 


Heuristics 

Violated 


Memory 

Visibility 

Error 
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increase  visibility;  Move  this  pull-down  to  a  more 
prominent  location  (top  left  comer;)  Display  patient’s 
name  along  with  AmbID, 


P:  Both  of  the  upper  two  other  cameras  are  actually 
menus  but  look  just  like  text  fields. 

S:  Change  the  background  of  the  pull-down  menus  to 
increase  visibility.  _ 


P:  Orientation  of  the  human  figure  is  ineongruent  with 
the  spatial  orientation  of  the  video  image. 

S;  Align  the  human  figure  with  video  image. 


P:  Numbers  for  the  preset  are  clickable  but  look  like 
text,  not  clickable  buttons.  Once  clicked,  the  feedback 
(the  number  becomes  red)  is  too  small. 

S:  The  two  should  be  combined  into  one  clickable 
icon. _ 


P;  Preset  cam  #1  does  not  work,  2  and  3  are  working 
S:  fix  the  bug _ 


P:  The  preset  is  patient-centered  while  the  zoom 
control  is  physician-centered. 

S;  Pick  either  one  but  not  both 


P:  The  zoom  controls  do  not  provide  sufficient 
feedback.  For  example,  when  the  physician  clicks  a 
zoom  button,  the  system  gives  no  indication  about  the 
zoom  level.  Even  when  the  camera  is  already  zoomed 
in  or  out,  the  buttons  are  still  clickable.  Also,  The 
meaning  of  and  “+”  signs  appear  to  be  arbitrary. 

S:  Display  several  zoom  levels  on  a  zoom  bar  and 
allow  the  physician  to  randomly  pick  one  at  any  time. 
Make  this  control  similar  to  the  one  used  on  the 
drivers  map. 


P:  If  caml  is  on,  the  physician  should  have  no  control 
but  the  controls  are  still  activated  and  clickable. 

S:  De-activate  camera  controls  and  make  sure  they  are 

visually  deactivated.  _ 

P:  Once  an  area  of  interest  is  selected,  if  the  physician 
left  clicks  the  mouse,  the  red  boundary  disappears  (but 
the  area  is  still  there.)  To  take  away  the  area,  one  has 
to  right  click  the  mouse. 

S:  Action  should  be  done  by  left-click.  Right  click  is 
for  selection 


P;  The  small  and  big  video  windows  are  out  of  sync. 
Changes  do  not  happen  at  the  same  time.  The  big 
video  window  changes  first. 

S:  fix  the  bug 


P:  The  two  other  cameras  do  not  have  thumbnail 
images  as  the  other  three. 
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S:  Provide  consistent  thumbnails  for  all  cams 

Vitals 

P:  On  the  middle  panel,  the  “X”  button’s  function  is 
hard  to  determine. 

S:  Label  this  button  in  text. 

Visibility 

3 

P:  On  “Auto  BP  control”  panel,  one  needs  to  go 
through  two  steps  to  set  interval  (first  click  a  number 
and  then  click  “set  interval”),  and  once  the  interval  is 
set,  there  is  no  visual  feedback  as  to  which  one  is  now 
in  effect. 

S:  Merge  the  two  steps  into  one  (clicking  a  number 
sets  the  interval.)  The  number  remains  depressed  to 
indicate  the  current  BP  interval. 

Minimalist 

Feedback 

2.67 

P:  Will  “Update  BP  Now”  overwrite  the  automatic  BP 
setting?  How  does  it  proceed  (does  the  paramedic 
need  to  get  the  BP  or  does  it  get  from  the  paramedic’s 
data  automatically?) 

S:  the  buttons  should  be  redesigned  to  avoid  the 
ambiguity. 

Visibility 

Match 

Memory 

3 

Did  not  find  “pause”  “unpause”  buttons. 

Map 

P:  Drop-down  menus  for  Range  and  Ambulance 
appear  to  be  text  fields 

S:  Change  background  of  the  pull-down  menus;  make 
the  down  arrow  visible. 

Visibility 

Consistency 

2.67 

P:  The  middle  button  on  the  map  control  panel 
(among  the  navigation  arrow  buttons)  has  two  modes 
“Center”  and  “scroll,”  but  they  are  not  readily  visible. 

S:  The  middle  button  should  not  be  used  as  a  mode 
button.  Same  as  on  the  paramedic’s  workstation. 

Visibility 

2.33 
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Table  1.3.  Heuristics  Violations:  by  Places  of  Occurrences 
-  Driver’s  Station 


Function: 

Section 

Problem  Description  (P) 

Recommended  Solution  (S) 

Heuristics 

Violated 

Severity 

Rating 

Overall 

P:  Top  address  fields  look  like  they  are  editable  but 
they  are  actually  not. 

S:  Display  the  information  in  text  instead  of  as  text 
fields. 

Visibility 

Consistency 

2.33 

Select 

Feature 

P:  Icons  are  hard  to  recognize  because  of  low  contrast. 
S:  Increase  contrast. 

Visibility 

3 

P:  Most  icons  do  not  appear  to  correspond  to  standard 
symbology  and  may  therefore  be  difficult  to 
understand. 

S;  Improve  icon  design  by  using  standard  icons  or 
designing  more  intuitive  icons. 

Consistency 

2,67 

P:  “Exit”  is  ambiguous  since  it  is  also  commonly  used 
in  computer  dialogue,  meaning  to  close  the  current 
window  or  application. 

S:  Change  to  “Road  Exit”. 

Message 

2.33 

Street 

Address: 

P:  No  default  value  for  town/city. 

S:  Should  default  to  the  town/city  in  which  the  EMS  is 
located. 

Flexibility 

Memory 

2.67 

Edit  street 
map 

P:  Radio  buttons  are  used  as  action  buttons. 

S:  Use  buttons  instead  of  radio  buttons. 

Consistency 

3 

Reference 

P:  Reference  points  are  labeled  as  No.l,  No.2,  etc. 
There  is  no  indication  as  to  what  a  reference  point 
represents.  Once  No.  1  is  removed,  the  original  No.  2 
becomes  No.  1. 

S:  Allow  a  user  to  label  reference  points.  Don’t 
change  the  numbers  when  a  point  is  deleted. 

Memory 

Consistency 

3 

P:  Zoom  control  is  far  away  from  Map  Display 
control  panel. 

S:  Put  the  two  next  to  each  other. 

visibility 

2 

Track 

Ambulance 

P:  Once  a  user  initiates  “Track  Ambulance”,  the 
system  provides  no  indication  about  the  current  mode, 
S;  Keep  the  “Track  Ambulance”  button  depressed,  or 
display  a  text  message  on  the  map.  Consider  a 
checkbox  next  to  track  ambulance:  if  checked  the 
ambulance  is  being  tracked,  otherwise  it  is  not. 

Feedback 

Memory 

Visibility 

3 

P:  Once  a  user  initiates  “calculating  route”,  there  is  no 
way  to  cancel  it,  though  the  button  is  there. 

Calculating  route  can  take  a  long  time  (more  than  a 
minute),  giving  users  an  impression  that  the  process 
might  be  dead. 

Control 

Feedback 

3.67 

Hide  route: 


On  the  map 


S:  Provide  a  way  to  cancel  this  process  and  show  its 
progress 


P:  Once  a  user  selects  “mark  destination”,  there  is  no 
feedback  on  the  map. 

S:  Mousepointer  should  change  to  indicate  the  mode. 


P:  On  the  Map  Display  control  panel,  N,  S,  W,  E  are 
also  clickable  but  they  do  not  look  like  they  are. 

S:  Add  arrows  on  these  buttons  and  put  N,  S,  W,  E 
outside  the  buttons. _ 


P:  There  is  no  feedback  to  show  that  the  route  is  there 
but  hidden. 

S:  Design  a  complimentary  “Show  Route”  button 
which  is  only  active  when  a  route  is  available,  but  has 
been  hidden. 


P:  There  is  no  way  to  find  out  what  an  icon  means. 
S:  Once  the  mouse  is  pointed  to  an  icon,  display  a 
tooltip  to  tell  what  it  represents. 


P:  The  map  is  not  directly  manipulable.  No  way  to 
directly  click  on  the  map  to  give  the  address  input. 
S:  make  the  objects  on  the  map  manipulable. 


P:  To  mark  the  destination,  one  has  to  click  just  on  the 
line  for  a  road.  The  system  doesn’t  accept  a  slightly 
off-line  click. 

S:  Make  it  more  flexible  while  accepting  a  mouse 
click  as  the  input. 


P:  Can’t  re-open  a  street  or  remove  a  landmark 
directly  on  the  map. 

S:  Allow  these  operations  directly  on  the  map. 


P:  When  removing  a  landmark,  the  button  says  “set” 
S:  Label  the  button  “Remove”. 


P:  Once  a  mode  is  selected,  the  mouse  pointer  doesn’t 
change  to  indicate  the  mode  one  is  in. 

S:  Provide  feedback  by  changing  the  mouse  pointer. 
Without  a  mouse  pointer  (such  as  with  the  touch 
screen),  provide  an  onscreen  visual  indication  of  the 
mode  die  system  is  in. 


P:  Once  calculating  a  route,  the  user  can’t  do  anything 
before  clicking  “clear  route”. 

S:  Add  a  “cancel”  button 


P:  No  heads-up  orientation  of  the  map. 

S:  Consider  providing  such  a  function  as  this  may  be 
the  most  useful  display  for  the  driver 


P:  When  putting  in  destination,  “street  destination”  is 
highlighted.  Click  again,  the  system  removes  the  route 
and  leaves  the  fields  empty. 

S;  fix  the  bug 


Feedback 

Visibility 


Control 

Visibility 

3 

Match 

2.33 

Bug? 

3.5 
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P;  The  system  crashed  when  the  address  did  not  match 
the  zip  code. 

S:  fix  the  bug 

P:  How  does  one  go  back  to  no-route  (to  remove  the 
route)  other  than  initiate  “new  route”? 

S:  provide  such  an  option 

System  response  is  too  slow. 

Bug? 


Control 
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Table  2.1.  Heuristics  Violations:  Sorted  by  Severity  Ratings 
-  Paramedic’s  Station 


Function: 
Section 
Run  Record: 
On-Scene 

Report 


Report: 

Report 

Overall 


Run  Record: 
On-Scene 


Run  Record: 
On-Scene 


Protocols 


Problem  Description  (P) 

Recommended  Solution  (S) _ 

P:  Scan  ID  in  to  create  a  new  record.  Once  you  click 
on  the  arrow,  the  record  is  gone. 

S:  fix  the  bug _ 

P:  The  text  entered  for  one  patient  is  displayed  for 
every  patient  once  the  patient  name  is  switched.  (Is  it 
saved?  Don’t  know.) 

S:  fix  the  bug _ 

P:  Once  a  record  is  created,  everything  from  the 
previous  report  is  copied. 

S:  fix  the  bug _ 

P;  Functions  “Run  Record”  and  “Report”  have  a 
number  of  sections  that  require  the  paramedic’s  input. 
It  is  not  clear  at  all  if  clicking  button  “Save  Current 
Record”  (on  Run  Record:  On-Scene)  saves  all  the 
information  or  each  section  needs  to  be  saved 
separately. 

S:  Provide  “Save  Data”  on  each  data  entry  page.  This 
button  should  be  in  the  same  place  on  every  page.  A 
more  systematic  solution  is  to  create  a  drop-down 
menu  that  contains  all  the  major  functions  common 
for  all  sections,  such  as  the  “File”  menu  on  ail 

Microsoft  products,  d.  _ 

P:  Modifying  the  first  or  last  name  creates  a 
completely  new  record. 

S:  Provide  feedback  (e.g.,  display  a  message)  prior  to 
automatically  generating  a  new  record.  This  should  be 
associated  with  the  “save”  function.  Use  “save”  to 
save  to  current  file  and  “save  as”  to  save  to  a  new  file. 
Again,  the  current  “save”  function  needs  to  be 

redesigned. _ 

P:  If  a  2nd  record  arrives  (a  new  ID  is  scanned  in,)  the 
1st  record  is  gone  without  warning  the  user.  And  there 
is  no  indication  of  whether  the  old  is  saved  or  not 
saved. 

S:  Provide  explicit  feedback  (e.g,,  display  a  message.) 
P;  Lots  of  problems.  It  needs  to  be  completely 
redesigned.  Just  a  few  examples  of  design  problems, 

1 .  Structure  of  the  screen  protocols  appears  to  be 
hierarchical  (title  with  six  types,)  but  in  fact  they  are 
parallel; _ _ 


Heuristics 

Violated 

bug 


bug 


bug 


Visibility 

Memory 

Consistency 

Feedback 


Consistency 

Feedback 

Error 

Match 


Error 

Visibility 

Undo 


Visibility 

Consistency 

Memory 

Match 


Overall 


Overall 


Run  Record: 
On-Scene 


Run  Record: 
Patient  TX 


Video/Vital 


2.  Cursor  doesn’t  change  on  html  links; 

3.  When  deep  in  the  structure,  no  indication  of  the 
level; 

4.  On  certain  pages,  there  is  an  invisible  but 
functional  “back”  button, 

S:  This  section  needs  to  be  completely  re-designed  to 
conform  to  web  design  standards.  For  example, 

1.  The  first  screen  should  be  called  “index”  page; 

2,  Always  provide  a  back  button  on  each  page. 

P:  Function  navigation  bar  is  separated  from  section 
tabs  within  each  function.  Major  functions  are  located 
at  the  bottom  of  the  screen,  whereas  the  tabs  on  the 
top  of  the  screen  represent  lower  level  sections.  This 
makes  it  hard  to  see  the  connections  between  the  two, 
and  requires  constant  moving  (and  looking)  up  and 
down  during  navigation.  This  problem  persisted  after 
we  gained  experience  with  the  system,  indicating  that 
it  will  not  disappear  with  experience. 

S:  Move  the  function  navigation  bar  to  the  top,  above 
the  section  tabs.  Use  a  two-level  tab  navigation  bar  at 

the  top. _ _ 

P:  There  is  no  visible  indication  of  whether  data  needs 
to  be  saved  or  whether  it  has  been  saved. 

S:  If  the  system  does  not  automatically  save  after 
every  entry,  provide  a  salient.indication  on  every 
screen  that  a  save  is  required.  One  way  to  do  this  is  by 
activating  and  visually  highlighting  the  Save  button 
anytime  a  save  is  required.  If  the  system  autosaves 
only  when  a  user  switches  to  a  different  page,  you 
must  still  provide  some  visible  indicator  on  each  page 
to  let  the  user  know  that  the  data  has  (or  has  not)  been 
saved;  otherwise,  the  user  will  not  know  whether  or 

not  the  data  has  been  autosaved. _ 

P:  No  feedback  once  “Save  Current  Record”  is 
clicked. 

S:  Provide  explicit  feedback  (e.g.,  change  the  cursor, 
or  display  a  message.)  Or  completely  redesign  the 

“save”  function  such  as  move  it  to  a  top  menu. _ 

P:  The  function  of  the  set  button  following  time  is  not 
clear  at  all.  No  feedback  after  it  is  clicked.  What 
happens  if  it  is  not  clicked?  Does  it  have  to  be  clicked 
for  something  to  happen?  Can  time  still  be  changed 
after  “set”  is  clicked? 

S:  Remove  it  if  is  redundant. _ 

P:  Patient’s  name  is  not  displayed.  What  happens  if 
there  is  more  than  one  patient  on  board? _ 


Visibility 

Consistency 

Match 

Memory 

Error 


Visibility 

Feedback 


Feedback 


Memory 

Feedback 

Visibility 


Visibility 

Match 


3.33 


3.33 


3.33 


3.33 


3.33 
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Report: 

Billing 


Run  Record: 
On-Scene 


Run  Record: 
On-Scene 


Run  Record: 
Narrative 


Report: 

Vitals 

Report 


Report: 

Vitals 

Report 


Run  Record: 
On-Scene 


S:  Display  patient’s  name  in  a  prominent  location 
(same  as  with  the  Run  Record  function.) 

Memory 

P:  The  middle  button  of  the  keypad  has  two  modes 
(GPS  and  scroll.)  Exactly  what  does  each  mode  mean? 
Also  in  scroll  mode,  clicking  on  an  arrow  causes  the 
mid  button  to  automatically  switch  to  GPS. 

S:  The  middle  button  should  not  be  used  as  a  mode 
button. 

Visibility 

Memory 

Bug 

P:  Patient  name  and  address  should  be  consistent  with 
the  information  obtained  in  other  sections. 

S:  Automatically  fill  in  the  slots  from  input  in  other 
sections. 

Minimalist 

Consistency 

Error 

P:  Patient’s  name,  currently  at  the  bottom,  is  difficult 
to  see,  both  because  of  its  font  size  and  of  its  location. 

S:  Display  patient’s  name  in  a  more  prominent 
location  (on  top,  near  the  section  tabs)  and  in  a  bigger 
font. 

Visibility 

P:  No  suggestion  on  re-saving  record  once  data  in  a 
section  is  modified. 

S;  If  information  in  a  section  is  changed,  before  the 
paramedic  switches  to  another  function  (section), 
display  a  message  as  a  reminder.  _ 

Visibility 

P;  The  function  of  this  section  is  not  very  clear. 

S:  If  both  the  paramedic  and  the  physician  can  provide 
input  here,  it  needs  to  have  two  separate  fields  for 
each  party  for  synchronization  purpose. 

Match 

P;  On  the  right  panel.  Destination,  TBD,  and  Range 
are  actually  pull-down  menus  but  it  is  impossible  to 
see  this  because  of  low  contrast  (Background  of  the 
menus  is  same  as  that  for  the  whole  screen  display.) 

S:  Change  their  background  to  increase  visibility. 

Visibility 

P:  Incident  does  not  tell  what  should  be  reported; 

Date:  no  format  indicated;  Dispatch  (Time):  no  format 
indicated;  when  impossible  data  are  entered,  the 
system  gives  no  error  message.  It  is  not  clear  what  the 
two  “set”  buttons  mean?  Once  clicked,  time  is  still 
editable. 

S:  use  examples  to  show  the  format.  Reconsider  the 
“set”  buttons. 

Error 

Visibility 

Memory 

P:  Can’t  switch  to  another  patient  on  this  page  though 
it  seems  to  allow  this, 

S:  either  remove  the  patient  selection  drop-down 
menu  to  disallow  the  switching  of  patient  or  make  it 
switch-able. 

Flexibility 

Visibility 

P:  If  no  patient’s  name  is  entered,  name  field  only 

displays 
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S:  The  system  should  designate  a  default  value  (e.g., 
patient  #1)  for  patients  whose  name  is  not  accessible. 


Run  Record: 
On-Scene 


P:  Create  new  record  does  not  update  the  patient’s 
name  at  the  bottom. 

S;  default  to  “New  Patient. 


Run  Record: 
Exam/Obser 
vation 


P:  Pull-down  menu  for  consciousness  does  not  cover 
the  full  range  of  consciousness. 

S:  Add  more  options  to  make  the  list  complete. 


Consistency 

Visibility 

Feedback 


2.67 


Match 


2.67 


Run  Record: 
Patient  TX 


P;  Medication  and  dosage/route  are  not  linked  (The 
latter  two  are  not  sensitive  to  the  value  in  the 
medication  slot.) 

S:  Make  the  options  for  Dosage  and  Route  contingent 
upon  input  in  the  Medicine  slot. 


Consistency 

Error 


2.67 


Run  Record: 
Patient  TX 


P:  No  indication  of  the  format  of  the  time. 

S;  Specify  the  format  of  the  time  by  giving  an 
example,  e.g.,  18:45 


Memory 

Match 


2.67 


Comms 


P:  All  the  options  are  not  clickable.  Besides,  the 
option  button  is  under  ICM  but  all  the  rest  are  located 
above  their  respective  channels. 

S:  If  options  do  not  serve  any  function,  remove  them. 


Consistency 

Visibility 


2.67 


Report: 

Billing 


P:  Bill  To:  options  as  buttons 
S:  use  radio  buttons  instead  of  buttons. 


Consistency 

Visibility 


2.67 


Report: 

Report 


P:  Ambiguous  section  meaning.  Also  print  to  a  printer 
in  the  ambulance  or  in  the  hospital? 

S:  Section  should  be  labeled  “Print”.  Also  should 
separate  “Print”  from  “Report”.  This  can  be  done  by 
adding  a  menu  bar  that  includes  save,  save  as,  print, 
exit,  etc. 


Consistency 

Match 


2.67 


Report: 

Report 


P:  What  if  there  is  more  than  one  patient?  In  Run 
record,  one  can  easily  choose  a  patient.  In  Report,  one 
can’t  do  this.  The  patient  is  set  to  whoever  is  selected 
in  run  record. 

S:  either  allow  switching  between  patients  here  or 
disallow  it  by  not  showing  the  drop-down  button. 


Flexibility 

Visibility 


2.67 


Overall 


P:  Pull-down  menus  in  data  entry  sections  also  allow 
the  paramedic  to  type  in  information  manually,  but  the 
arrow  buttons  give  the  impression  that  one  can  only 
select  from  the  menu. 

S:  Emphasize  this  in  training;  Set  default  for  pull- 
down  menus  as  “type  or  select” 


Visibility 

Consistency 


2.33 


Run  Record: 
On-Scene 


P:  Buttons  “Create  New  Record”  and  “Save  Current 
Record”  are  inconsistent  with  the  rest  of  the  buttons 
and  are  difficult  to  see. 

S:  Use  a  consistent  button  design.  Place  “create  new 
record”  and  “save  current  record”  at  the  top  of  the 
page,  separated  from  the  data  fields.  Consider  adding 


Consistency 

Visibility 

Match 

Consistency 


2.33 
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Run  Record: 
On-Scene 


Run  Record: 
Exam/Obser 
vation 


Run  Record: 
Exam/Obser 
vation 


Run  Record: 
Patient  HX 


Comms 


Report: 

Release: 


Report: 

Transport/C 

rew 


a  menu  bar  containing  one  or  more  menus  at  the  top 
for  common  and  frequent  tasks. 


P:  In  the  vehicle  pop-up  menu,  if  the  mouse  is  on  the 
top  half  of  the  arrow  button  when  it  is  clicked,  the 
menu  won’t  stay  (hitting  “van”);  if  on  the  bottom  half, 
then  the  menu  stays; 

S:  Use  radio  buttons  or  small  graphics  to  display 
options,  instead  of  the  pop-up  menu.. 


P;  The  question  mark  besides  the  Glascow  scale  is  not 
dear  in  terms  of  its  meaning.  It  should  also  be  put 
inside  the  boundary  box  surrounding  the  Glascow 
scale. 

S;  Label  the  “?”  button  in  text. 


P:  The  Left,  Right  Pupil  pull-down  menus  also  allow 
type-in  but  each  has  only  two  choices. 

S;  If  there  are  only  two  choices,  it  is  better  to 
implement  as  radio  buttons  or  at  least  not  allow  type- 
in. 


P:  What  happens  if  one  is  allergic  to  more  than  one 
item  in  a  category  (how  is  the  information  entered?) 
S:  Display  all  allergies  in  each  category  and  allow  the 
paramedic  to  check  all  that  applies;  Or  ask  the 

s. _ 


P:  Address  fields  on  the  top  allow  selection  by  mouse 
and  appear  to  be  editable,  but  the  user  is  not  allowed 
to  edit  them. 

S:  Display  the  information  as  pure  text,  not  as  a  text 
box  field. _ 


P:  On  and  Off  look  like  radio-buttons,  giving  the  false 
impression  that  they  are  clickable. 

S;  If  this  information  is  redundant  with  Throughput, 
consider  removing  it  completely. 


P;  Options  for  relationships  are  not  complete. 
S;  Should  include  more  choices. 


P:  Zip  code  slot  and  tel  #  slot  allow  for  text  as  input. 
S:  These  two  slots  should  allow  only  numbers. 


P;  Date  slots  are  not  constrained,  and  format  is  not 
specified 

S:  This  slot  should  only  allow  number  input  and 
format  should  be  indicated 


P:  Patient  transported  to  slot  should  read  directly  from 
map  information. 

S:  Automatically  fill  in  the  slots  from  input  in  other 
sections. 


P:  First  5  items  are  from  Rim  Record,  the  last  4  are 
from  Report. 


Bug 

Match 

Visibility 

2.33 

Visibility 

Memory 

2.33 

Visibility 

Minimalism 

2.33 

Match 

Flexibility 

2.33 

Consistency 

Visibility 

2.33 

Consistency 

Visibility 

2.33 

Match 

2.33 

Error 

2.33 

Error 

2.33 

Minimalist 

Memory 

2.33 

WMfmm 

2.33 
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Run  Record: 
Exam/Obser 
vation 


Run  Record: 
Patient  TX 


Report 


Comms 


Report: 

Release: 


Run  Record: 
Exam/Obser 
vation 


S:  Should  provide  separation  between  these  two 
categories. _ 


P:  No  way  to  change  the  image  (gender  of  the  patient) 
from  this  page,  the  user  must  return  to  the  page 
containing  demographic  data. 

S:  Set  up  two  radio  buttons  above  the  image  to  allow 
the  paramedic  to  change  the  gender. 


P;  “Responses  to  TX”  is  separate  from  the  medication 
(listed  above.)  There  could  be  a  number  of 
medications  but  there  is  only  one  response  slot  (Note 
this  may  not  be  a  problem  at  all.) 

S:? 


P;  Once  you  click  on  “report”,  the  last  section  in  the 
previous  “report”  session  is  the  default.  There  is  no 
absolute  default  page  (even  across  patients.) 

S:  Set  a  default  section. 


P:  Bandwidth  is  displayed  in  numbers.  It  could  be  a 
bit  too  complicated  for  paramedics. 

S:  Could  be  better  implemented  as  araohs. 


P;  No  way  to  input  signature. 

S:  Should  this  page  be  printed  out  and  have  patients 
sign  on  paper?  _ 


You  ean  have  only  one  number  on  the  body  image,  but 
it  allows  you  to  add  more  symptom  items  (Note:  this 
may  not  be  a  usability  problem  at  all  if  it  is  ok  for  the 
paramedic  to  enter  symptoms  here  without  specifying 
where  they  are  on  the  body  image.) 

No  connections  between  die  numbers  and  the  GUI 
widgets. 


Control 

Flexibility 


Match 


Consistency 

Match 


Match 


Table  2.2.  Heuristics  Violations:  Sorted  by  Severity  Ratings 


—  Physician’s  Station 


Function: 

Section 

Problem  Description  (P) 

Recommended  Solution  (S) 

Heuristics 

Violated 

Severity 

Rating 

Overall 

P:  No  indication  as  to  which  EMS  (of  multiple  ones) 
the  current  record  is  from. 

S:  Display  the  AmblD/patient’s  name  on  EACH 
function/section  page,  and  at  a  prominent  location. 

Memory 

Visibility 

Error 

4 

Videos 

P:  Preset  cam  #1  does  not  work,  2  and  3  are  working 

S:  fix  the  bug 

bug 

4 

Overall 

P:  How  does  the  physician  know  how  to  divide  his  or 
her  time  among  different  ambulances/patients?  The 
patient  list  does  not  provide  information  for  the 
physician  to  determine  priority. 

S:  more  information  should  be  provided  such  that  the 
ER  physicians  can  make  informed  decisions. 

Memory 

3.33 

Videos 

P:  The  zoom  controls  do  not  provide  sufficient 
feedback.  For  example,  when  the  physician  clicks  a 
zoom  button,  the  system  gives  no  indication  about  the 
zoom  level.  Even  when  the  camera  is  already  zoomed 
in  or  out,  the  buttons  are  still  clickable.  Also,  The 
meaning  of  and  “+”  signs  appear  to  be  arbitrary. 

S:  Display  several  zoom  levels  on  a  zoom  bar  and 
allow  the  physician  to  randomly  pick  one  at  any  time. 
Make  this  control  similar  to  the  one  used  on  the 
drivers  map. 

Visibility 

Feedback 

Error 

3.33 

Videos 

P:  Once  an  area  of  interest  is  selected,  if  the  physician 
left  clicks  the  mouse,  the  red  boundary  disappears  (but 
the  area  is  still  there.)  To  take  away  the  area,  one  has 
to  right  click  the  mouse. 

S;  Action  should  be  done  by  left-click.  Right  click  is 
for  selection 

Consistency 

3.33 

Run  Record: 
On-Scene 

P:  The  “Refresh  Records”  button  (a  function  button) 
is  embedded  in  the  patient’s  data  and  hard  to  see.  Also 
clicking  this  button  gives  no  feedback. 

S:  Move  this  button  to  a  more  prominent  location  (at 
the  top,  near  the  section  tabs.)  Provide  visual  feedback 
(change  the  cursor  or  display  a  message)  when  the 
physician  clicks  this  button.  Or  integrate  it  into  a  top 
menu  bar  with  other  major  functions  such  as  “save”. 

Visibility 

Feedback 

3 

Videos 

P:  AmbID  is  a  pull-down  menu  but  is  hard  to  see 
because  of  low  contrast;  the  patient’s  name  is  not 
shown  here. 

S:  Change  the  background  of  the  pull-down  menu  to 

Consistency 

visibility 

3 
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Videos 


Vitals 


Videos 


Videos 


increase  visibility;  Move  this  pull-down  to  a  more 
prominent  location  (top  left  comer;)  Display  patient’s 
name  along  with  AmblD. 


P:  The  small  and  big  video  windows  are  out  of  sync. 
Changes  do  not  happen  at  the  same  time.  The  big 
video  window  changes  first. 

S:  fix  the  bug  _ 


P;  On  the  middle  panel,  the  “X”  button’s  function  is 
hard  to  determine. 

S;  Label  this  button  in  text. 


P:  Will  “Update  BP  Now”  overwrite  the  automatic  BP 
setting?  How  does  it  proceed  (does  the  paramedic 
need  to  get  the  BP  or  does  it  get  from  the  paramedic’s 
data  automatically?) 

S;  the  buttons  should  be  redesigned  to  avoid  the 
ambiguity. _ 


P:  All  sections  within  “Run  Record”  are  much  the 
same  as  on  the  paramedic’s  station.  However,  the 
normal  text  fields  and  pull-down  menus  (though 
deactivated)  give  rise  to  the  false  impression  that  the 
physician  can  change  the  data.  There  is  no  indication 
that  they  will  never  be  active. 

St  If  the  data  are  never  editable,  display  them  in  pure 
text  instead  of  in  text  box  fields.  If  the 
eontrols/buttons  can  never  be  used,  remove  them  from 
the  screen..  If  the  controls  may  sometimes  be  used, 
find  a  way  to  make  these  items  look  inactive  and  make 
sure  the  users  know  how  to  activate  them. 


P:  Numbers  for  the  preset  are  clickable  but  look  like 
text,  not  clickable  buttons.  Once  clicked,  the  feedback 
(the  number  becomes  red)  is  too  small. 

S:  The  two  should  be  combined  into  one  clickable 
icon.  _ 


P;  If  caml  is  on,  the  physician  should  have  no  control 
but  the  controls  are  still  activated  and  clickable. 

S:  De-activate  camera  controls  and  make  sure  they  are 
visually  deactivated. _ 


P:  On  “Auto  BP  control”  panel,  one  needs  to  go 
through  two  steps  to  set  interval  (first  click  a  number 
and  then  click  “set  interval”),  and  once  the  interval  is 
set,  there  is  no  visual  feedback  as  to  which  one  is  now 
in  effect. 

S:  Merge  the  two  steps  into  one  (clicking  a  number 
sets  the  interval.)  The  number  remains  depressed  to 
indicate  the  current  BP  interval. 


P:  Drop-down  menus  for  Range  and  Ambulance 


Bug? 

3 

Visibility 

3 

Visibility 

Match 

Memory 

3 

Match 

Consistency 

Visibility 

2.67 

Visibility 

2.67 

Visibility 

Match 

2.67 

Minimalist 

Feedback 

2.67 

Visibility 

2.67 
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appear  to  be  text  fields 

S:  Change  background  of  the  pull-down  menus;  make 
the  down  arrow  visible. 

Consistency 

Run  Record: 
On-Scene 

P:  Message  displayed  beside  the  vehicle  is 
inconsistent  with  the  actual  action  allowed  (the 
physician  should  not  set  anything  for  the  vehicle 
involved.) 

S;  Take  away  the  message  and  the  arrow  button  to  the 
right  of  the  vehicle  image. 

Message 

Consistency 

Visibility 

2.33 

Videos 

P:  Both  of  the  upper  two  other  cameras  are  actually 
menus  but  look  just  like  text  fields. 

St  Change  the  background  of  the  pull-down  menus  to 
increase  visibility. 

Consistency 

Visibility 

2.33 

Videos 

P:  Orientation  of  the  human  figure  is  incongruent  with 
the  spatial  orientation  of  the  video  image. 

S:  Align  the  human  figure  with  video  image. 

Match 

2.33 

Videos 

P:  The  two  other  cameras  do  not  have  thumbnail 
images  as  the  other  three. 

S:  Provide  consistent  thumbnails  for  all  cams 

Consistency 

2.33 

Map 

P:  The  middle  button  on  the  map  control  panel 
(among  the  navigation  arrow  buttons)  has  two  modes 
“Center”  and  “scroll,”  but  they  are  not  readily  visible. 

S:  The  middle  button  should  not  be  used  as  a  mode 
button.  Same  as  on  the  paramedic’s  workstation. 

Visibility 

2.33 

Videos 

P:  The  preset  is  patient-centered  while  the  zoom 
control  is  physician-centered, 

S:  Pick  either  one  but  not  both 

Match 

2 

Vitals 

Did  not  find  “pause”  “unpause”  buttons. 
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Table  2.3.  Heuristics  Violations:  Sorted  by  Severity  Ratings 


-  Driver’s  Station 


Function: 

Section 

Problem  Description  (P) 

Recommended  Solution  (S) 

Heuristics 

Violated 

Severity 

Rating 

On  the  map 

System  response  is  too  slow. 

4 

On  the  map 

P:  The  system  crashed  when  the  address  did  not 
match  the  zip  code. 

S:  fix  the  bug 

Bug 

4 

Track  Ambulance 

P:  Once  a  user  initiates  “calculating  route”,  there” 
is  no  way  to  cancel  it,  though  the  button  is  there. 
Calculating  route  can  take  a  long  time  (more 
than  a  minute),  giving  users  an  impression  that 
the  process  might  be  dead. 

S:  Provide  a  way  to  cancel  this  process  and 
show  its  progress 

Control 

Feedback 

3.67 

On  the  map 

P:  When  putting  in  destination,  “street 
destination”  is  highlighted.  Click  again,  the 
system  removes  the  route  and  leaves  the  fields 
empty. 

S:  fix  the  bug  _ 

Bug? 

3.5 

Select  Feature 

P:  Icons  are  hard  to  recognize  because  of  low 
contrast. 

S:  Increase  contrast. 

Visibility 

3 

Edit  street  map 

P:  Radio  buttons  are  used  as  action  buttons. 

S:  Use  buttons  instead  of  radio  buttons. 

Consistency 

3 

Reference 

P:  Reference  points  are  labeled  as  No.l,  No.2, 
etc.  There  is  no  indication  as  to  what  a  reference 
point  represents.  Once  No.  1  is  removed,  the 
original  No.  2  becomes  No.  1. 

S:  Allow  a  user  to  label  reference  points.  Don’t 
change  the  numbers  when  a  point  is  deleted. 

Memory 

Consistency 

3 

Track  Ambulance 

P:  Once  a  user  initiates  “Track  Ambulance”,  the 
system  provides  no  indication  about  the  current 
mode. 

S:  Keep  the  “Track  Ambulance”  button 
depressed,  or  display  a  text  message  on  the  map. 
Consider  a  checkbox  next  to  track  ambulance:  if 
checked  the  ambulance  is  being  tracked, 
otherwise  it  is  not. 

Feedback 

Memory 

Visibility 

3 

On  the  map 

P:  To  mark  the  destination,  one  has  to  click  just 
on  the  line  for  a  road.  The  system  doesn’t  accept 
a  slightly  off-line  click. 

S:  Make  it  more  flexible  while  accepting  a 
mouse  click  as  the  input. 

Flexibility 

3 
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On  the  map 


Select  Feature 


Street  Address: 


Track  Ambulance 


Hide  route: 


On  the  map 


On  the  map 


On  the  map 


On  the  map 


Overal 


Select  Feature 


On  the  map 


P:  Once  calculating  a  route,  the  user  can’t  do 
anything  before  clicking  “clear  route”. 

S:  Add  a  “cancel”  button 


P:  Most  icons  do  not  appear  to  correspond  to 
standard  symbology  and  may  therefore  be 
difficult  to  understand. 

S:  Improve  icon  design  by  using  standard  icons 
or  designing  more  intuitive  icons. 


P:  No  default  value  for  town/city. 

S:  Should  default  to  the  town/city  in  which  the 
EMS  is  located. _ 


P:  Once  a  user  selects  “mark  destination”,  there 
is  no  feedback  on  the  map. 

S:  Mousepointer  should  change  to  indicate  the 
mode. _ 


P:  There  is  no  feedback  to  show  that  the  route  is 
there  but  hidden. 

S:  Design  a  complimentary  “Show  Route” 
button  which  is  only  active  when  a  route  is 
available,  but  has  been  hidden. 


P:  The  map  is  not  directly  manipulable.  No  way 
to  directly  click  on  the  map  to  give  the  address 
input. 

S:  make  the  objects  on  the  map  manipulable. 


P:  When  removing  a  landmark,  the  button  says 
“set” 

S:  Label  the  button  “Remove”. 


P:  Once  a  mode  is  selected,  the  mouse  pointer 
doesn’t  change  to  indicate  the  mode  one  is  in. 
S:  Provide  feedback  by  changing  the  mouse 
pointer.  Without  a  mouse  pointer  (such  as  with 
the  touch  screen),  provide  an  onscreen  visual 
indication  of  the  mode  the  system  is  in. 


P:  How  does  one  go  back  to  no-route  (to  remove 
the  route)  other  than  initiate  “new  route”? 

S:  provide  such  an  option 


P:  Top  address  fields  look  like  they  are  editable 
but  they  are  actually  not. 

S:  Display  the  information  in  text  instead  of  as 
text  fields. 


P:  “Exit”  is  ambiguous  since  it  is  also 
commonly  used  in  computer  dialogue,  meaning 
to  close  the  current  window  or  application. 

S:  Change  to  “Road  Exit”. 


P:  There  is  no  way  to  find  out  what  an  icon 
means. 


Control 

Visibility 


Consistency 


Flexibility 

Memory 


Visibility 

Feedback 


Feedback 

Visibility 


Control 


Consistency 

language 


Feedback 

Visibility 


Control 

2.5 

Visibility 

2.33 

Consistency 

Message 

2.33 

Memo 
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S:  Once  the  mouse  is  pointed  to  an  icon,  display 
a  tooltip  to  tell  what  it  represents. 

On  the  map 

P:  No  heads-up  orientation  of  the  map. 

S:  Consider  providing  such  a  function  as  this 
may  be  the  most  useful  display  for  the  driver 

Match 

2.33 

Reference 

P:  Zoom  control  is  far  away  from  Map  Display 
control  panel. 

S:  Put  the  two  next  to  each  other. 

Visibility 

2 

Track  Ambulance 

P;  On  the  Map  Display  control  panel,  N,  S,  W,  E 
are  also  clickable  but  they  do  not  look  like  they 
are. 

S:  Add  arrows  on  these  buttons  and  put  N,  S,  W, 

E  outside  the  buttons. 

Visibility 

2 

On  the  map 

P:  Can’t  re-open  a  street  or  remove  a  landmark 
directly  on  the  map. 

S:  Allow  these  operations  directly  on  the  map. 

Control 

2 
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1.  EXECUTIVE  SUMMARY 


The  following  report  gives  the  results  of  the  heuristic  evaluation  of  the  mockup  of  DEMS 
version  2  created  for  Liberty  County  Paramedics. 

As  guided  by  the  design  team,  we  only  focused  on  the  higher  level  usability  issues,  not  the 
detailed  GUI  designs. 

It  is  important  to  realize  that  heuristic  evaluations  do  not  reveal  major  missing  functionality,  the 
compatibilities  between  system  functions  and  user  tasks,  and  the  workflow  of  the  tasks.  Other 
usability  engineering  techniques,  such  as  functional,  user,  and  task  analyses  can  indicate  what  is 
right  with  the  system  and  identify  the  most  appropriate  functionality.  We  are  in  an  early  of 
conducting  a  task  analysis  for  DEMS. 

We  found  47  violations  of  the  14  usability  heuristics  for  higher  level  usability  design  in  the 
mockup.  Visibility  and  Match  are  the  two  heuristics  with  most  violations  (13  and  9, 
respectively).  The  next  two  categories  are  Consistency  and  Language,  each  with  7  violations. 

There  are  2  catastrophic  violations  that  received  severity  ratings  over  3.50.  It  is  imperative  to  fix 
them.  15  violations  are  major  violations  (severity  ratings  between  2.50  and  3.50)  that  are 
important  to  fix  and  should  be  given  high  priority.  9  violations  are  minor  violations  (between 
1.50  and  2.50)  that  have  low  priority  in  fixing 

For  every  heuristic  violation,  we  recommended  a  potential  solution.  Tables  1  and  show  the 
details  of  the  violations  and  recommended  solutions. 

Please  note  again  that  we  need  to  use  other  techniques  to  cover  other  higher-level  usability 
issues. 


2.  METHODOLOGY 

The  heuristics  evaluation  methodology  adopted  here  is  a  discount  usability  technique  that  is  used 
to  identify  the  major  usability  problems  of  a  product  in  a  timely  manner  with  reasonable  cost. 
This  technique  requires  three  or  more  usability  experts  to  independently  apply  a  set  of  usability 
heuristics  to  a  product,  identify  violations  of  the  heuristics,  and  assess  the  severity  of  each 
violation. 

The  three  usability  experts  (evaluators)  for  the  evaluation  of  Digital  EMS  Version  2  Mockup  are 
Dr.  Jiajie  Zhang,  Dr.  Todd  R.  Johnson,  and  Ms.  Zhihua  Tang.  They  evaluated  the  user  interface 
and  generated  a  list  of  heuristics  violations  according  to  the  fourteen  heuristics  described  below. 
This  list  was  given  to  the  three  evaluators  who  then  independently  accessed  the  severity  of  each 
violation.  The  ratings  from  the  three  evaluators  were  averaged.  The  averaged  ratings  are 
reported.  The  next  two  sections  describe  the  usability  heuristics  used  for  Digital  EMS  and  the 
scale  of  the  severity  rating. 
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2,1  Usability  Heuristics 


The  following  fourteen  heuristics  were  developed  by  Jiajie  Zhang  and  Todd  R.  Johnson.  The 
words  in  the  brackets  are  the  semantic  tags  for  the  heuristics. 

1.  [Consistency]  Consistency  and  Standards.  Users  should  not  have  to  wonder  whether 
different  words,  situations,  or  actions  mean  the  same  thing.  Standards  and  conventions  in 
web  design  should  be  followed. 

a.  Sequences  of  actions  (skill  acquisition) 

b.  Color  (categorization) 

c.  Layout  and  position  (spatial  consistency) 

d.  Font,  capitalization  (levels  of  organization) 

e.  Terminology  (delete,  del,  remove,  rm)  and  language  (words,  phrases) 

f.  Standards  (e.g.,  blue  underlined  text  for  unvisited  hyperlinks) 

2.  [Visibility]  Visibility  of  System  State.  Users  should  be  always  informed  what  is  going 
on  with  the  system  through  appropriate  feedback  and  display  of  information. 

a.  What  is  the  current  state  of  the  system? 

b.  What  can  be  done  at  current  state? 

c.  Where  can  users  do? 

d.  What  change  is  made  after  an  action? 

3.  [Match]  Match  between  System  and  World.  The  image  of  the  system  perceived  by 
users  should  match  the  model  the  users  have  about  the  system. 

a.  User  model  matches  system  image 

b.  Actions  provided  by  the  system  should  match  actions  performed  by  users 

c.  Objects  on  the  system  should  match  objects  of  the  task 

4.  [Minimalist]  Minimalist.  Any  extraneous  information  is  a  distraction  and  a  slow-down. 

a.  Less  is  more 

b.  Simple  is  not  equivalent  to  abstract  and  general 

c.  Simple  is  efficientProgressive  levels  of  detail 

5.  [Memory]  Minimize  Memory  Load.  Users  should  not  be  required  to  memorize  a  lot  of 
information  to  carry  out  tasks.  Memory  load  reduces  users’  capacity  to  carry  out  the  main 
tasks. 

a.  Recognition  vs.  recall  (e.g.,  menu  vs.  commands) 

b.  Externalize  information  through  visualization 

c.  Perceptual  procedures 

d.  Hierarchical  structure 

e.  Default  values 

f.  Concrete  examples  (DD/MM/YY,  e.g.,  10/20/99) 

g.  Generic  rules  and  actions  (e.g.,  drag  objects) 

6.  [Feedback]  Informative  Feedback.  Users  should  be  given  prompt  and  informative 
feedback  about  their  actions. 

a.  Direct  perception  (7  stage  model) 
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b.  Information  that  can  be  directly  perceived  and  interpreted, 

c.  Levels  of  feedback  (novice  and  expert) 

d.  Concrete  and  specific,  not  abstract  and  general. 

e.  Response  time 

•  0,1  second  for  instantaneously  reacting 

•  1.0  second  for  uninterrupted  flow  of  though 

•  10  seconds  for  the  limit  of  attention 

7.  [Flexibility]  Flexibility  and  efficiency.  Users  always  learn  and  users  are  always 
different.  Give  users  the  flexibility  of  creating  customization  and  shortcuts  to  accelerate 
their  performance. 

a.  Shortcuts  for  experienced  users 

b.  Shortcuts  or  macros  for  frequently  used  operations 

c.  Skill  acquisition  through  chunking 

d.  Examples: 

•  Abbreviations,  function  keys,  hot  keys,  command  keys,  macros,  aliases, 
templates,  type-ahead,  bookmarks,  hot  links,  history,  default  values,  etc. 

8.  [Message]  Good  Error  Messages.  The  messages  should  be  informative  enough  such  that 
users  can  understand  tire  nature  of  errors,  learn  from  errors,  and  recover  from  errors. 

a.  Phrased  in  clear  language,  avoid  obscure  codes 

•  e.g.,  “system  crashed,  error  code  147” 

b.  Precise,  not  vague  or  general. 

•  e.g.,  “Cannot  open  document” 

c.  Constructive 

d.  Polite 

•  e.g.,  “illegal  user  action”,  “job  aborted”,  “system  was  crashed”,  “fatal 
error”,  etc. 

9.  [Error]  Prevent  Errors.  It  is  always  better  to  design  interfaces  that  prevent  errors  from 
happening  in  the  first  place. 

a.  Interfaces  that  make  errors  impossible. 

b.  Avoid  modes  (e.g.,  vi,  text  wrap,).  Or  use  informative  feedback,  e.g.,  different 
sounds. 

c.  Execution  error  vs,  evaluation  error 

d.  Various  types  of  slips. 

10.  [Closure]  Clear  Closure.  Every  task  has  a  beginning  and  an  end.  Users  should  be  clearly 
notified  about  the  completion  of  a  task. 

a.  Clear  beginning,  middle,  and  end. 

b.  Complete  7-stages  of  actions. 

c.  Clear  feedback  to  indicate  goals  are  achieved  and  current  stacks  of  goals  can  be 
released. 

•  e.g.,  dialogues. 
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11.  [Undo]  Reversible  Actions.  Users  should  be  allowed  to  recover  from  errors.  Reversible 
actions  also  encourage  exploratory  learning. 

a.  At  different  levels:  a  single  action,  a  subtask,  or  a  complete  task 

b.  Multiple  steps 

c.  Encourage  exploratory  learning 

d.  Prevent  serious  errors 

12.  [Language]  Use  Users’  Language.  The  language  should  be  always  presented  in  a  form 
understandable  by  the  intended  users. 

a.  Use  standard  meanings  of  words 

b.  Specialized  language  for  specialized  group 

c.  User  defined  aliases 

d.  Users’  perspective 

•  e.g.,  “we  have  bought  four  tickets  for  you”  vs,  “you  bought  four  tickets” 

13.  [Control]  Users  in  Control.  Don’t  give  users  that  impression  that  they  are  controlled  by 
the  systems. 

a.  Users  are  initiators  of  actors,  not  responders  to  actions. 

b.  Avoid  surprising  actions,  unexpected  outcomes,  tedious  sequences  of  actions,  etc. 

14.  [Document]  Help  and  Documentation.  Always  provide  help  when  needed. 

a.  Context-sensitive  help 

b.  Four  types  of  help 

•  task-oriented 

•  alphabetically  ordered 

•  semantically  organized 

•  search 

c.  Help  embedded  in  contents 

2.2  Severity  Rating  Scale 

The  following  scale  is  used  for  the  assessment  of  the  severity  of  each  heuristic  violation. 

0  =  1  don't  agree  that  this  is  a  usability  problem  at  all 

1  =  Cosmetic  problem  only:  need  not  be  fixed  unless  extra  time  is  available  onproject 

2  =  Minor  usability  problem:  fixing  this  should  be  given  low  priority 

3  =  Major  usability  problem:  important  to  fix,  so  should  be  given  high  priority 

4  =  Usability  catastrophe:  imperative  to  fix  this  before  product  can  be  released 

As  a  guideline  for  rating  the  problems,  we  consider  the  proportion  of  users  who  will  experience 
it,  the  impact  it  will  have  on  their  experience  with  the  product,  and  whether  the  usability  problem 
will  be  a  problem  only  the  first  time  they  encounter  it,  or  whether  it  will  persistently  bother  them. 
A  persistent  problem  with  a  major  impact  that  most  users  will  encounter  will  get  the  highest 
severity  rating. 
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3.  RESULTS 


Figures  1,  2,  and  3  show  the  heuristics  violations  in  Digital  EMR  Version  2  Moekup  along 
different  dimensions.  See  the  figure  captions  for  explanations.  Table  shows  details  of  the 
violations  ordered  by  places  of  occurrences,  and  Table  2  shows  them  sorted  by  severity  ratings. 
Potential  solutions  were  recommended  for  all  the  violations  in  the  tables. 


Frequencies  of  Heuristics  Violations  by  Heuristics  Categories 


Heuristics  Categories 


Figure  1.  The  14  usability  heuristics  used  for  evaluations  were  violated  47  times.  Visibility  and 
Match  are  the  two  heuristics  with  most  violations  (13  and  9,  respectively).  The  next  two 
categories  are  Consistency  and  Language,  each  with  7  violations. 
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Cosmetic 


Frequencies  of  Heuristics  Violations  by  Severity 


Severity  Rating 


Figure  2.  There  are  2  catastrophic  violations  that  received  severity  ratings  over  3,50,  It  is 
imperative  to  fix  them.  15  violations  are  major  violations  (severity  ratings  between  2,50  and 
3.50)  that  are  important  to  fix  and  should  be  given  high  priority.  9  violations  are  minor  violations 
(between  1,50  and  2.50)  that  have  low  priority  in  fixing. 
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Table  1.  Heuristics  Violations:  by  Places  of  Occurrences 


Slide# 

Problem  Description  (P) 

Recommended  Solution  (S) 

Heuristics 

Violated 

Mi 

Overall 

“Shut  Down”  button  appears  as  a  sub-menu  item 
(located  on  the  right  side)  on  many  slides.  For  the 
purpose  of  enabling  instant  system  shut  down,  it  is 
better  to  keep  it  at  a  fixed  location  at  the  bottom  of 
the  screen,  where  the  top-level  menu  items  are 
displayed. 

Consistency 

Visibility 

Flexibility 

Error 

3.33 

P:  The  two  levels  of  navigation  bars  are  not 
visually  distinct  and  their  hierarchical  structure  is 
not  visually  perceivable. 

S:  The  two  levels  of  navigation  bars  should  be 
made  visually  distinct,  and  their  relation  should  be 
made  clear. 

Visibility 

3.50 

#1,  Login 

P:  The  system  could  be  shut  down  by  clicking  the 
“Shut  Down”  button  unintentionally. 

S:  Once  the  button  “Shut  Down”  is  clicked,  the 
system  should  provide  a  message  for  user’s 
confirmation. 

Undo 

Error 

3.67 

#2,  System/ 
System  Menu 

P:  The  meanings  of ’’systems”  and  “system  menu” 
are  not  clear. 

S:  Labeled  the  two  in  a  different  way  (e.g., 

“System  Menu”  may  be  labeled  “Overview”). 

Match 

Language 

2.50 

P:  The  patient  name  list  contains  three  variables.  It 
could  be  hard  to  immediately  recognize  a  patient’s 
name  from  the  list. 

S:  The  name  list  should  be  organized  to  fit  the  task 
(the  most  important  information  should  be 
displayed  first).  Also,  should  there  be  a  default 
patient?  It  would  be  good  if  the  three  variables  of 
the  patient  can  be  sorted. 

Visibility 

Flexibility 

Control 

2.33 

#3,  Medic 

Sign  In/Out 

P:  Medic’s  name  is  displayed  in  three  fields  that 
are  visually  separated. 

S:  Display  a  medic’s  name  in  one  field. 

Visibility 

2.0 

P:  The  process  to  sign  in/out  is  not  based  on  the 
object-action  paradigm  (i.e.,  select  a  person  and 
perform  an  action.) 

S:  Add  two  more  buttons,  “Sign  In”  and  “Change 
Skill”,  on  the  display,  to  go  along  with  “Sign  Out”. 
When  “Sign  In”  is  clicked,  popup  window  appears 
for  login.  When  “change  skill”  is  clicked,  only  the 
skill  set  is  displayed.  When  “sign  out”  is  clicked, 
only  password  is  prompted. 

Consistency 

Match 

Visibility 

3.33 
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#4,  Manage 
Run  Records 


#5,  Active  Run 
Records/ 
Personal 
Info/Med  HX 


Problem  Description  (P)  I  Heuristics 

Recommended  Solution  (S) _  Violated 


P:  The  Sign-In  pop-up  window  has  a  button  Match 

“Change  Skill”.  When  a  medic  newly  signs  in,  Flexibility 
what  needs  to  be  done  is  to  set,  rather  than  to 
change,  skill  level. 

S:  This  might  be  better  implemented  as  a  pull¬ 
down  menu  labeled  as  “Set  Skill”.  See  the 

previous  discussion.  _ 

P:  The  word  “load”  is  used  to  label  column  or  Language 

buttons.  This  word  pertains  more  to  the  software  Match 

than  to  the  medic’s  task,  and  so  may  not  be  easily 
understood. 

S:  Use  the  word  “activate”  instead  of  “load”  for 
labels  (e.g.,  “Activated?”,  “Activate  Record”  and 
“Deactivate  Record”. _ 


P:  The  functions  of  the  buttons  “Audit  &  Close”  Language 
and  “Transmit  &  Purge”  are  not  quite  clear. 

S:  If  the  two  functions  on  one  single  button  are 
always  bundled  together,  it  is  better  to  re-label 
these  two  buttons  and  make  sure  that  the  labels  are 

easy  to  understand. _ 

P:  Medication  has  three  relevant  fields  Visibility 

“Medication”,  “Route”  and  “Dosage”.  The  two 

buttons  below,  “Add”  and  “Delete”,  are  separated; 

giving  the  false  impression  that  each  applies  to 

different  field.  The  two  buttons  under  fields 

“Allergies”  and  “Symptoms”  have  the  same 

problems. 

S:  Put  the  respective  “Add”  and  “Delete”  buttons 
close  to  each  other. _ 


P:  When  a  patient’s  driver’s  license  is  scanned  in,  Feedback 
the  pop-up  window  for  confirmation  does  not  Visibility 
provide  any  information  that  has  just  been  scanned  Memory 
in.  The  user  may  not  know  whether  the  data  being 
display  is  the  data  for  the  patient  whose  card  is  just 
scanned. 

S:  The  pop-up  window  should  display  the 
information  just  scanned  in.  _ 


General  consideration:  Needs  task 

How  does  the  system  deal  with  multiple  patients?  analysis 
The  answer  to  this  question  will  determine  how  to 
make  the  design  match  the  workflow. 
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Slide# 


#7,  On-Scene 


#8,  Vital  Signs 


#9, 

Observations 


Problem  Description  (P) 
Recommended  Solution  (S 


P:  “Auto  Insurance”  and  “Police  Crash  Report”  do 
not  look  like  they  are  clickable  and  editable. 

S:  Provide  visual  cue  to  indicate  that  these  two  are 
clickable.  Or  consider  change  it  to  another  format. 
P:  “Propaq  on  this  Patient”  is  implemented  as  a 
button  but  actually  it  indicates  a  state  (whether 
Propaq  is  connected  to  the  patient).  This  is  called 
“object-symbol” — states  and  actions  are 
implemented  on  the  same  object.  This  is  good  for 
many  device  designs.  However,  it  is  rarely  used  in 
computer-based  GUI. 

S:  It  is  better  to  use  checkbox  (Is  Propaq  on  this 
patient?  Yes  No)  instead  of  button. 


P:  The  label  of  the  button  “Propaq  Capture”  is  not 
task  oriented. 

S:  Label  die  button  “Capture  Vital  Signs”. 


P:  The  waveform  section  does  not  have  any  title 
that  provides  more  information  about  this  section, 
as  the  remaining  parts  on  the  display  do. 

S:  Provide  caption  for  this  section 


General  consideration: 

1 .  Captured  waveforms  should  be  time- 
stamped; 

2.  Need  to  consider  the  display  order  of 
captured  waveforms; 

3.  Consider  the  timing  of  taking  vital  signs. 
This  will  determine  where  to  put  the  menu 
item  on  the  screen. 


P:  The  “Skin”  box  does  not  look  like  it  is 
clickable. 

S:  Provide  visual  cues  to  make  it  function  known. 
See  the  comments  for  #8,  Vital  Signs. 


P:  The  list  of  Illness/Symptoms  (in  the  pop-up 
window  once  the  “Add”  button  is  clicked)  is  not 
organized.  It  is  also  hard  to  read  (search)  through 
the  list  because  of  the  centering  of  the  text. 

S:  Organize  the  list  in  a  meaningful  way  (e.g., 
functionally  or  spatially).  Make  the  text  left- 
adjusted.  This  requires  user  and  task  analyses 


Heuristics  Severity 

Violated  Rating 

2.67 


Consistency  3.0 
Visibility 


Language  2.67 
Match 


Visibility  2.33 
Consistency 


Needs  task  3.0 
analysis 


Consistency  2.67 
Visibility 


Match  3.0 

Visibility 
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Slide# 

Problem  Description  (P) 

Recommended  Solution  (S) 

Heuristics 

Violated 

Severity 

Rating 

P:  The  sequence  to  indicate  the  illness  on  the  body 
is  not  clear.  Once  the  button  “Add”  is  clicked,  the 
system  waits  for  the  user  to  indicate  the  location 
on  the  body  but  gives  no  indication. 

S:  Provide  a  message  when  the  “Add”  button  is 
clicked.  Or  reverse  the  sequence  so  that  the  user 
first  clicks  on  the  body  and  then  click  “Add”.  Or 
clicking  a  body  part  brings  the  pop-up  box 
directly. 

Visibility 

Flexibility 

Feedback 

3.33 

#10, 

Treatment/ 

Techniques 

Considerations: 

1 .  The  meanings  of  buttons  “Stop  Med”  and 
“Stop”  are  not  clear  to  us. 

2.  What  is  the  purpose  of  ECG  here  and  how 
does  it  relate  to  “Vital  Signs”. 

Need  user 
and  task 
analysis 

3.0 

#11-13,  Forms 

P:  The  labeling  of  the  signature  fields  is  not 
complete. 

S:  Label  as  “Patient’s  signature”, 

“Paramedic/EMT  signature”,  etc.,  wherever  is 
appropriate. 

Consistency 

Match 

2.33 

#14,  Sign  and 
Close  Run 
Records 

P:  The  title  on  the  top  of  the  slide  does  not  match 
that  on  the  menu. 

S:  Make  the  two  the  same. 

Consistency 

2.33 

#15,  Comms 

P:  The  labeling  of  the  menu  item  “Comms”  is  not 
clear. 

S:  Label  it  more  explicitly. 

Language 

2.0 

P:  The  top  right  section  is  titled  “Physician  View”. 
This  labeling  is  incongruent  with  the  current  task. 

S:  Label  this  section  from  the  medic’s  point  of 
view  (e.g.,  “Data  Sent”). 

Match 

Language 

2.67 

General  consideration: 

Redefine  the  purpose  of  this  page  and  the  function 
of  each  button. 

Needs  task 
analysis 

#16, 

Navigation 

P:  The  word  “Navigation”  may  cause  ambiguity 
since  it  could  also  mean  navigation  through  the 
system. 

S:  Label  the  slide  and  the  menu  item  “Map” 
instead. 

Language 

2.33 

General  consideration: 

Refer  to  the  comments  for  the  previous  version. 

#19,  Admin/  General  consideration: 

Network  Status  Refer  to  the  comments  for  the  previous  version 
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Table  2.  Heuristics  Violations:  Sorted  by  Severity  Ratings 


Slide  # 

Problem  Description  (P) 

Recommended  Solution  (S) 

Heuristics 

Violated 

Severity 

Rating 

#1,  Login 

P:  The  system  could  be  shut  down  by  clicking  the 
“Shut  Down”  button  unintentionally. 

S:  Once  the  button  “Shut  Down”  is  clicked,  the 
system  should  provide  a  message  for  user’s 
confirmation. 

Undo 

Error 

3.67 

Overall 

P:  The  two  levels  of  navigation  bars  are  not  visually 
distinct  and  their  hierarchical  structure  is  not 
visually  perceivable. 

S:  The  two  levels  of  navigation  bars  should  be  made 
visually  distinct,  and  their  relation  should  be  made 
clear. 

Visibility 

3.50 

#3,  Medic 

Sign  In/Out 

P:  The  process  to  sign  in/out  is  not  based  on  the 
object-action  paradigm  (i.e.,  select  a  person  and 
perform  an  action.) 

S:  Add  two  more  buttons,  “Sign  In”  and  “Change 
Skill”,  on  the  display,  to  go  along  with  “Sign  Out”. 
When  “Sign  In”  is  clicked,  popup  window  appears 
for  login.  When  “change  skill”  is  clicked,  only  the 
skill  set  is  displayed.  When  “sign  out”  is  clicked, 
only  password  is  prompted. 

Consistency 

Match 

Visibility 

3.33 

#9, 

Observations 

P:  The  sequence  to  indicate  the  illness  on  the  body 
is  not  clear.  Once  the  button  “Add”  is  clicked,  the 
system  waits  for  the  user  to  indicate  the  location  on 
the  body  but  gives  no  indication, 

S:  Provide  a  message  when  the  “Add”  button  is 
clicked.  Or  reverse  the  sequence  so  that  the  user  first 
clicks  on  the  body  and  then  click  “Add”.  Or  clicking 
a  body  part  brings  the  pop-up  box  directly. 

Visibility 

Flexibility 

Feedback 

3.33 

Overall 

“Shut  Down”  button  appears  as  a  sub-menu  item 
(located  on  the  right  side)  on  many  slides.  For  the 
purpose  of  enabling  instant  system  shut  down,  it  is 
better  to  keep  it  at  a  fixed  location  at  the  bottom  of 
the  screen,  where  the  top-level  menu  items  are 
displayed. 

Consistency 

Visibility 

Flexibility 

Error 

3.33 

#10, 

Treatment/ 

Techniques 

Considerations: 

3.  The  meanings  of  buttons  “Stop  Med”  and 
“Stop”  are  not  clear  to  us. 

4.  What  is  the  purpose  of  ECG  here  and  how 
does  it  relate  to  “Vital  Signs”. 

Need  user 
and  task 
analysis 

3.0 
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#5,  Active  Run 
Records/ 
Personal 
Info/Med  HX 


#8,  Vital  Signs 


#8,  Vital  Signs 


#9, 

Observations 


#3,  Medic 
Sign  In/Out 


Problem  Description  (P) 
Recommended  Solution  fS 


P:  When  a  patient’s  driver’s  license  is  scanned  in, 
the  pop-up  window  for  confirmation  does  not 
provide  any  information  that  has  just  been  scanned 
in.  The  user  may  not  know  whether  the  data  being 
display  is  the  data  for  the  patient  whose  card  is  just 
scanned. 

S:  The  pop-up  window  should  display  the 
information  just  scanned  in. 


P:  “Propaq  on  this  Patient”  is  implemented  as  a 
button  but  actually  it  indicates  a  state  (whether 
Propaq  is  connected  to  the  patient).  This  is  called 
“object-symbol”— states  and  actions  are 
implemented  on  the  same  object.  This  is  good  for 
many  device  designs.  However,  it  is  rarely  used  in 
computer-based  GUI. 

S:  It  is  better  to  use  checkbox  (Is  Propaq  on  this 
patient?  Yes  No)  instead  of  button. 


General  consideration: 

4.  Captured  waveforms  should  be  time- 
stamped; 

5.  Need  to  consider  the  display  order  of 
captured  waveforms; 

6.  Consider  the  timing  of  taking  vital  signs. 
This  will  determine  where  to  put  the  menu 
item  on  the  screen. 


P:  The  list  of  Illness/Symptoms  (in  the  pop-up 
window  once  the  “Add”  button  is  clicked)  is  not 
organized.  It  is  also  hard  to  read  (search)  through  the 
list  because  of  the  centering  of  the  text. 

S:  Organize  the  list  in  a  meaningful  way  (e.g., 
functionally  or  spatially).  Make  the  text  left- 
adjusted,  This  requires  user  and  task  analyses 


s  titled  “Physician  View”, 
ent  with  the  current  task, 
n  the  medic’s  point  of  view 


P:  The  Sign-In  pop-up  window  has  a  button 
“Change  Skill”.  When  a  medic  newly  signs  in,  what 
needs  to  be  done  is  to  set,  rather  than  to  change,  skill 
level. 

S:  This  might  be  better  implemented  as  a  pull-down 
menu  labeled  as  “Set  Skill”.  See  the  previous 
discussion. 


Heuristics 

Violated 


Feedback 

Visibility 

Memory 


Sever 

Ratin 


3.0 


Consistency 

Visibility 


Needs  task 
analysis 


Match 

Visibility 


Match 

Language 


Match 

Flexibility 
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Slide# 


#4,  Manage 
Run  Records 


#7,  On-Scene 


#8,  Vital  Signs 


#9, 

Observations 


#2,  System/ 
System  Menu 


#11-13,  Forms 


#14,  Sign  and 
Close  Run 
Records 


#16, 

Navigation 


#2,  System/ 
System  Menu 


Problem  Description  (P) 
Recommended  Solution  (S 


P:  The  word  “load”  is  used  to  label  column  or 
buttons.  This  word  pertains  more  to  the  software 
than  to  the  medic’s  task,  and  so  may  not  be  easily 
understood. 

S:  Use  the  word  “activate”  instead  of  “load”  for 
labels  (e.g.,  “Activated?”,  “Activate  Record”  and 
“Deactivate  Record”. 


P:  “Auto  Insurance”  and  “Police  Crash  Report”  do 
not  look  like  they  are  clickable  and  editable. 

S:  Provide  visual  cue  to  indicate  that  these  two  are 
clickable.  Or  consider  change  it  to  another  format. 


P:  The  label  of  the  button  “Propaq  Capture”  is  not 
task  oriented. 

St  Label  the  button  “Capture  Vital  Signs”, 


P:  The  “Skin”  box  does  not  look  like  it  is  clickable, 
S:  Provide  visual  cues  to  make  it  function  known. 
See  the  comments  for  #8,  Vital  Signs. 


Heuristics 

Violated 


Language 

Match 


P:  The  labeling  of  the  signature  fields  is  not 
complete. 

St  Label  as  “Patient’s  signature”,  “Paramedic/EMT 
signature”,  etc.,  wherever  is  appropriate. 


Pt  The  title  on  the  top  of  the  slide  does  not  match 
that  on  the  menu. 

St  Make  the  two  the  same. _ 


Pt  The  word  “Navigation”  may  cause  ambiguity 
since  it  could  also  mean  navigation  through  the 
system. 

St  Label  the  slide  and  the  menu  item  “Map”  instead. 


Pt  The  patient  name  list  contains  three  variables.  It 
could  be  hard  to  immediately  recognize  a  patient’s 
name  from  the  list, 

St  The  name  list  should  be  organized  to  fit  the  task 
(the  most  important  information  should  be  displayed 
first).  Also,  should  there  be  a  default  patient?  It 
would  be  good  if  the  three  variables  of  the  patient 
can  be  sorted. 


Visibility  2.67 
Match 


Language  2.67 
Match 


Consistency  2,67 
Visibility 


Match  2.50 

Language 


Consistency  2.33 
Match 


Consistency  2.33 


Language  2.33 


Visibility  2.33 

Flexibility 

Control 


Slide# 


#5,  Active  Run 
Records/ 
Personal 
Info/Med  HX 


#8,  Vital  Signs 


#15,  Comms 


#3,  Medic 
Sign  In/Out 


#4,  Manage 
Run  Records 


#6,  Run 
Record 
Information 


#15,  Comms 


#19,  Admin/ 
Network  Status 


Problem  Description  (P) 
Recommended  Solution  fS 


P:  Medication  has  three  relevant  fields 
“Medication”,  “Route”  and  “Dosage”.  The  two 
buttons  below,  “Add”  and  “Delete”,  are  separated; 
giving  the  false  impression  that  each  applies  to 
different  field.  The  two  buttons  under  fields 
“Allergies”  and  “Symptoms”  have  the  same 
problems. 

S:  Put  the  respective  “Add”  and  “Delete”  buttons 

close  to  each  other.  _ 

P:  The  waveform  section  does  not  have  any  title  that 
provides  more  information  about  this  section,  as  the 
remaining  parts  on  the  display  do. 

S:  Provide  caption  for  this  section _ 

P:  The  labeling  of  the  menu  item  “Comms”  is  not 
clear. 

S:  Label  it  more  exolicitlv. 


P:  Medic’s  name  is  displayed  in  three  fields  that  are 
visually  separated. 

S:  Display  a  medic’s  name  in  one  field. 


P;  The  functions  of  the  buttons  “Audit  &  Close”  and 
“Transmit  &  Purge”  are  not  quite  clear. 

S:  If  the  two  functions  on  one  single  button  are 
always  bundled  together,  it  is  better  to  re-label  these 
two  buttons  and  make  sure  that  the  labels  are  easy  to 
understand. 


General  consideration: 

How  does  the  system  deal  with  multiple  patients? 
The  answer  to  this  question  will  determine  how  to 
make  the  design  match  the  workflow. 


General  consideration: 

Redefine  the  purpose  of  this  page  and  the  function 
of  each  button. 


General  consideration: 

Refer  to  the  comments  for  the  previous  version. 


General  consideration: 

Refer  to  the  comments  for  the  previous  version 


Heuristics  Sever 
Violated  Ratin 


Visibility  2,33 


Visibility  2.33 
Consistency 


Language  2,0 


Visibility  2.0 


Needs  task 
analysis 


Needs  task 
analysis 


Language  2.0 
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Abstract 


The  Digital  EMS  (DEMS)  software  development  plan  calls  for  several  key  elements  to  ensure  a  quality  product  with  which  the 
customer  will  be  satisfied.  These  areas  are  as  follows:  customer  requirements  definition,  functional  requirements  definition, 
testing  plan  (includes  independent  verification  and  validation  in  a  dedicated  testing  environment),  and  emergency  scenario  based 
testing  scripts.  Together,  these  elements  will  provide  a  foundation  to  test  the  Digital  EMS  software.  This  document  will  focus 
on  the  documenting  of  DEMS  software  development  including  the  interagency  interactions  (policy  &  procedure) 
specifications  and  diagrams  {DEMS  software  development  Task  1). 
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1.  Background 


The  Digital  EMS  is  a  conventional  ambulance  that  has  been  augmented  with  the  latest  technology  to  provide  a  means  of 
communication  between  the  paramedics  and  the  hospital  physicians.  The  aim  of  this  project  is  to  extend  the  expertise  of  the 
physicians  to  a  remote  location.  With  enhanced  communications,  which  entails  real  time  video,  audio,  and  data  streams  inter¬ 
networked  between  the  hospital  and  ambulance,  physicians  will  be  able  to  advise  the  paramedics  on  procedures  and  methods 
that  otherwise  would  not  be  possible.  As  a  side  benefit,  the  Digital  EMS  (DBMS)  will  provide  extra  functionality  to  the 
remotely  located  paramedics  such  as:  real  time  map  navigation,  enroute  emergency  protocol  documentation,  online  run 
record  reporting,  and  online  training. 

Together,  Digital  EMS(DEMS)  and  Interact™  are  the  centerpiece  of  the  Disaster  Relief  and  Emergency  Medical  Services 
(DREAMS™)  project.  DREAMS™  is  using  rapidly  developing  computer  and  telecommunications  technology  and  new 
research  in  basic  and  clinical  science  to  improve  trauma  victims’  survival,  especially  in  remote  areas  and  battlefields  beyond 
the  physical  reach  of  specialists  in  well-equipped  trauma  centers. 

Testing  of  the  concept  and  technology  behind  Digital  EMS  has  been  underway  in  suburban  Houston  since  1 995.  The 
project  s  efforts  are  focusing  on  using  the  Digital  EMS  digital  communications  technology  to  bring  life  -saving  care  for 
trauma  victims  to  rural  areas  of  the  country  and  other  places  beyond  the  reach  of  conventional  emergency  rooms.  Planners 
expect  the  high-capacity  digital  communications  system  eventually  will  be  used  to  upgrade  trauma  care  at  small  rural 
hospitals  and  be  installed  in  trauma  helicopters.  It  will  be  used  to  treat  trauma  casualities  anywhere  conventional  advanced 
emergency  medical  treatment  Is  unavailable  -  in  military  operations,  offshore  drilling  operations  and  NASA  orbital  missions. 

Through  DEMS,  help  arrives  in  real  time.  This  speed  is  possible  because  of  sophisticated  digital  data  and  Image  acquisition, 
compression,  and  information  processing  and  communications  management  techniques  engineers  are  now  combining  into  a 
reliable,  easy-to-use  package. 


Digital  EMS  combines  real-time  physician  mentoring  of  emergency  personnel,  provide  access  to  patients’  medical  records, 
advanced  therapies  and  up-to-date  regional  ambulance  and  hospital  availability  to  be  sure  each  patient  is  transported  to  the 
appropriate  facility  in  the  shortest  time. 

2.  Purpose 


The  purpose  of  this  document  is  to  define  the  software  functional  requirements  associated  with  the  design  and  development 
of  the  Digital  Emergency  Medical  System  (DEMS). 

3.  Agencies  Providing  DEMS  Functional  Requirements 

The  agencies  that  are  involved  in  providing  DEMS  functional  requirements  are  Liberty  County 
Emergency  Medical  Services  (LCEMS),  University  of  Texas  Health  Science  Center 
Houston(UTHSCH),  Texas  A&M  University  System  (TAMUS),  and  Herman  Hospital(H-H).  Included 
in  the  notes  of  a  technical  meeting  held  at  TEES  dated  06-26-2002  an  example  is  provided  of  the  above 
listed  agencies  and  their  contribution  and  effect  on  DEMS  functional  requirements.  An  excerpt  of  their 
contribution  is  shown  next.  For  more  detail  see  “Summary  of  Technical  Meeting  Held  at  TEES,  2002- 
06-26”  page  21  of  this  document. 

UTHSCH  will  provide  to  TAMUS  a  data  dictionary  of  all  of  the  concepts  contained  in  the  LCEMS  run 
sheets,  medical  protocols,  and  SOPs.  Data  dictionary  will  include:  concept  id  number,  concept  name 
(short),  concept  name  (long),  concept  definition,  reference  name,  reference  name  source,  type  of  value 
(text,  integer,  float,  coded,  etc.),  normal,  abnormal,  critical,  and  absolute  ranges  (where  appropriate),  is 
it  a  repeated  measure,  and  the  units  of  measure  to  be  used  (where  appropriate). 
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UTHSCH  will  work  with  TAMUS  to  create  one  or  more  information  models  to  represent  the 
clinical  and  non-clinical  information  about  each  patient  care  encounter  (this  includes  the  incident 
information,  vehicle  information,  administrative  information,  and  patient-care  information).  These 
information  models  will  be  used  to  instantiate  a  database,  provide  an  intellectual  model  for  use 
when  designing  and  discussing  patient  care  and  clinical  decision  support,  provide  a  foundation  for 
data  interchange  functions. 

TAMUS  will  instantiate  the  data  model  in  a  manner  that  meets  the  clinical  data  needs  of  the 
physicians,  EMTs,  and  provider-extenders  (e.g.,  medical  protocols).  Instantiation  may  be  in  the 
form  of  a  database. 

TAMUS  will  develop  APIs  to  the  instantiated  data  model  to  meet  the  medical  data  storage  and 
retrieval  needs.  UTHSCH  will  provide  a  list  of  the  needed  functions. 

4.  DEMS  Functional  Requirements  Definition 

This  section  provides  a  high  level  description  of  the  functionality  of  each  area  of  the  DEMS  software. 

4.1  The  Physician’s  Functional  Requirements  Definition 


The  Physician’s  functional  requirements  area  shall  comprise  a  workstation  environment, 
associated  software,  and  telecommunications  resources  to  allow  the  Physician  monitoring  the 
EMTs  (EMS  field  team)  sufficient  functionality  to  utilize  the  full  capacities  of  the  DEMS 
environment.  The  Physician’s  workstation  facility  shall  include  a  table  surface,  a  computer 
workstation  (of  sufficient  resources  to  facilitate  the  operation),  video  monitors,  telephones, 
computer  networking  facilities,  cameras,  and  microphones  as  needed. 

4.1.1  Run  Record  Display 


This  functional  area  allows  the  Physician  to  be  able  to  view  patient  run  records.  The  run  record  is 
subdivided  into  five  pages  of  forms  with  the  first  page,  entitled  “On-Scene,”  containing  basic 
patient  and  incident  information  and  a  motor/vehicle  survey.  All  run  record  data  entered  by 
ambulance  paramedics  is  automatically  transmitted  to  the  hospital  at  specified  time  intervals,  thus 
ensuring  that  the  Physician  is  viewing  up-to-date  run  record  data  at  all  times.  Located  in  the 
bottom  border  of  the  “Interact™”  window  are  a  small  arrow  button  and  non-editable  field 
identifying  the  patient’s  name.  The  Physician  can  switch  between  patients’  forms  by  pressing  the 
small  arrow  button,  which  displays  a  pop-up  list  of  patients  currently  stored  in  the  system.  The 
Physician  is  restricted  to  read-only  viewing  of  the  run  records,  currently  based  on  “LOCATION” 
(e.g.  Ambulance  1,  Ambulance  2,  etc.)  with  1  patient  per  LOCATION,  and  cannot  modify  any 
data.  The  Physician  Workstation  H-H  needs  to  be  able  to  handle  multiple  LOCATIONS  with 
multiple  patients  per  LOCATION.  The  “Exam/Observation”  page  of  the  run  record  contains  the 
primary  survey  of  the  patient.  The  “Patient  HX”  page  of  toe  run  record  contains  background 
history  of  toe  patient.  The  “Patient  TX”  page  of  the  run  record  contains  a  timestamp  log  of  all 
medications  administered  to  toe  patient.  The  “Narrative”  page  of  toe  run  record  contains  free- 
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form  text  area  in  which  the  Physician  can  view  the  narrative  details  of  the  incident  scene, 
transport,  treatment  and  treatment  response  of  the  patient. 

4.1.2  Video  Display  and  Control 


This  functional  area  allows  the  Physician  to  be  able  to  immediately  view  video  of  the  patient  as 
well  as  vitals  sign  patient  data.  Three  on-board  cameras  have  been  integrated  into  the  DEMS  , 
enhancing  communication  between  the  ambulance  and  the  hospital  by  providing  the  Physician  on 
call  with  a  virtual  “window”  into  the  ambulance.  The  Physician  has  full  rotation  and  zoom 
control  over  the  three  on-board  cameras. 


4.1.3  Sound 


This  functional  area  will  allow  the  Physician  to  be  able  to  hear  and  record  all  sounds  coming  from 
the  ambulance  in  real  time.  This  is  to  ensure  that  the  Physician  can  hear  both  the  enroute  patient 
and  the  paramedics. 

4.1.4  Vitals  Sign  Display 

The  Physician  will  be  able  to  see  real  time  readout  of  the  patient’s  major  vitals  signs:  heart  rate, 
blood  pressure,  and  air  flow. 

4.1.5  Mapping  Display 

This  is  a  map  that  shows  the  location  of  the  ambulance,  its  direction  of  travel,  and  its  estimated 
arrival  time. 


4.2  The  Paramedic’s  Functional  Requirements  Definition 

The  Paramedic’s  functional  area  shall  comprise  a  mobile  workstation  environment  (fully  contained 
in  the  ambulance),  associated  software,  and  telecommunications  resources  to  allow  the  Paramedics 
in  the  EMS  to  sufficiently  convey  the  situation  in  the  DEMS  environment.  The  ambulance  shall 
include  three  cameras,  microphone,  speaker,  two  workstations,  vitals  sign  monitor,  and  a  means  of 
communicating  the  data  back  to  the  hospital  workstation, 

4.2.1  Automated  Emergency  Run  Record  Management 

The  Paramedics  shall  be  able  to  enter  all  of  the  information  as  described  in  section  4.1.1  above. 

4.2.2  Video  Display 

This  functional  area  allows  the  Paramedics  to  be  able  to  immediately  view  video  of  the  patient  as 
well  as  vitals  sign  patient  data.  Three  on-board  cameras  have  been  integrated  into  the  DEMS, 
enhancing  communication  to  the  hospital  by  providing  the  Physician  on  call  a  virtual  “window” 


74 


into  the  ambulance.  The  Physician  has  full  rotation  and  zoom  control  over  the  three  on-board 
cameras.  The  Video/Vitals  screen  enables  the  Paramedics  to  view,  in  real  time,  the  exact  camera 
angle,  zoom,  and  resulting  video  that  is  being  transmitted  to  the  Physician. 

4.2.3  Vitals  Sign  Display 

A  Propaq  vitals  signs  monitor  (Protocol  System,  Inc.)  has  also  been  integrated  into  DEMS, 
enabling  real-time  patient  vitals  sign  display,  capture,  and  transmission.  This  enhances  the 
Paramedic’s  ability  to  not  only  review  historical  vitals  signs  data  for  post- incident  review,  but  also 
provides  timely  communication  of  the  patient’s  condition  to  the  hospital  Physician.  This 
Video/Vitals  screen  displays  both  the  live  video  transmitted  to  the  Physician  as  well  as  the 
patient’s  vitals  sign  data. 

4.2.4  Emergency  Protocols 

This  functional  area  will  provide  the  Paramedics  with  a  flow-based,  nominal  set  of  agency- 
approved  protocols  which  the  Paramedic  may  access  and  perform  without  Physician  apparoval. 
The  Protocol  pages  are  implemented  in  standard  hypertext  markup  languang  (HTML)  format  in 
which  underlined  words  contain  links  to  other  pages.  This  enables  the  Paramedics  to  simply  press 
on  the  desired  linked  text  to  rapidly  drill  down  to  the  desired  medical  protocol.  Since  this  format 
is  widely  supported  across  software  applications  and  the  World  Wide  Web,  additional  protocols 
can  be  integrated  quickly  with  little  modification. 

4.2.5  Mapping  and  Navigation  Interface 

This  functional  area  will  allow  the  Paramedics  to  be  able  to  enter  an  address  or  GPS  coordinate  as 
a  destination,  and  the  computer  will  calculate  and  display  the  best  (fastest)  route  to  the  destination 
form  the  current  position.  It  also  displays  the  current  location  and  a  map  of  the  surrounding 
environment. 

4.2.6  Communications  Display 

This  functional  area  will  allow  the  Paramedics  to  be  able  to  view  and  modify  parameters  affecting 
data  communication  to  the  hospital.  The  Intelligent  Communications  Manager  (ICM)  will 
automatically  determine  available  bandwidth  and  reliability  of  all  communication  mediums  at  all 
times  and  coordinates  their  usage  so  as  to  maximize  successful  data  transmission.  From  this 
screen,  the  Paramedics  can  view  maximum  and  actual  throughput  values  as  well  as  change 
communication  parameters  and  enable/disable  a  communication  medium  altogether.  This  screen 
is  offered  merely  as  a  troubleshooting  service  to  the  Paramedics,  since  communication  will  be 
optimized  automatically  via  the  ICM. 

4.2.7  Run  Record  Report 


This  functional  area  will  allow  the  Paramedics  to  be  able  to  view  and  modify  time- insensitive 
billing  and  insurance  information.  The  report  data  is  not  automatically  transmitted  to  the  hospital 
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since  it  in  not  time-critical  information.  However,  it  is  backed  up  on  the  Paramedic’s  system 
(DEMS).  The  Report  section  is  subdivided  into  five  pages  of  forms.  The  first  page,  entitled 
“Vitals  Report”  contains  basic  incident  information.  The  bottom  half  of  this  screen  is  reserved  for 
viewing  historical  Propaq  vitals  sign  data  which  will  be  under  development  in  the  near  future. 

The  “Billing”  page  of  the  run  record  contains  responsible  party  and  insurance  information  for  the 
patient.  The  “Release”  page  of  the  run  record  report  contains  Release  of  Responsibility  and 
Acknowledgment  sections.  With  this  fcrm  the  patient  can  acknowledge  that  medical  care  was  not 
recommended  and  that  he/she  is  denying  care.  The  Transport/Crew  page  of  the  run  record  report 
contains  patient  transport  method,  authorizing  Physician,  and  destination  of  the  patient.  The 
“Report”  page  of  the  run  record  report  will  enable  the  Paramedics  to  preview  or  print  the  entire 
run  record  or  only  selected  portions. 

4.2,8  Training 

This  functional  area  will  allow  the  Paramedics  to  be  able  to  receive  computer-based  training 
(CBT)  on-board  the  ambulance.  The  online  training  will  provide  a  variety  of  interactive  medical 
training  courses  that  can  be  integrated  into  the  DEMS  that  utilize  2D  and  3D  illustrations,  video, 
voice,  testing  and  feedback  to  provide  a  professional  curriculum  and  meet  national  standards  of 
the  Department  of  Transportation.  Integrating  interactive,  multimedia  courses  enables  Paramedics 
to  analyze  case  studies  of  real  emergency  calls,  refresh  and  test  their  knowledge  of  EMS 
protocols,  or  consult  an  on-  line  medical  dictionary  at  any  time  the  ambulance  is  powered  up  or 
enroute. 

5.  DEMS  Functional  Requirements  for  (Agency)  Liberty  County 


The  software  functional  requirements  are  separated  into  two  main  categories  or  functional  areas 
(Actor:  Physician’s  workstation  H-H,  Actor:  Paramedics).  All  of  the  software  in  the  Digital  EMS  is  a 
sub-  function  of  one  of  these  two  functional  areas. 

1.  DBMS  Physician’s  workstation  H-H  functional  area: 

1 . 1  Run  Record  Display 

1*1*1  Provide  a  display  of  the  non-modiflable  copy  of  the  Emergency  Run 

Records  being  produced  and/or  modified  in  the  ambulance 

1 .1.1.1  The  physician  shall  be  able  to  annotate  the  run  record 

1*1*2  AH  run  record  data  entered  by  ambulance  paramedics  is  automatically  transmitted  to  the  hospital  at 
specified  time  intervals 

1  *  1*3  DEMS  Displays  five  pages  of  patient  information: 

1.13.1  On-Scene: 

1.13.1.1  Shows  patient  information  and  information  about  the  scene  and  the  situation  of  the 
emergency 

1.13.1.2  The  physician  will  be  able  to  switch  between  patients*  forms(pages) 

1*13.13  The  physician  will  be  restricted  to  read-only  viewing  of  the  run  records 

1 . 1 3.2  Exam/Observation: 

1 . 1 3.2. 1  Will  contain  the  primary  survey  of  the  patient 

1 . 1 3.2.2  Shows  what  data  has  been  entered  as  input  on  the  paramedic’s  interface 

1.133  Patient  HX: 

1 . 1 33. 1  Shows  the  background  history  of  the  patient 

1 . 1 33.2  Information  obtained  by  verbal  communication  with  the  patient  and  an  upload  of  the 
hospitals  database 
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1.1. 3.4  Patient  TX: 

1.1 .3.4.1  This  is  a  timestamp  log  of  all  medications  administered  to  the  patient 

1 . 1 .3.4.2  Shows  what  was  given,  how  much  was  given,  and  when  it  was  given 

LI. 3,5  Narrative: 

1, 1,3.5, 1  This  is  a  free-form  text  area  in  which  the  physician  can  view  the  narrative  details  of  the 

incident  scene,  transport,  treatment  and  treatment  response  of  the  patient 

1 .2  Video  Display  and  Control 

1 .2. 1  Provide  three  viewing  angles/positions 

1.2.1. 1  One  camera  is  a  Medic-Cam 

1 .2. 1 .2  The  other  two  are  mounted  cameras 

1 .2.2  Provide  pan,  tilt,  and  zoom  capabilities  for  each  camera 

1.2.3  Provide  option  to  increase  frame  rate  by  selecting  area  of  screen  for  high  resolution 

1 .2.4  Provide  video  at  30  frames  per  second 

1 .2.5  Provide  video  display  at  a  resolution  of  at  least  640x480 

1.3  Sound 

1.3.1  Provide  sound  support 

1.3.1. 1  The  physician  shall  be  able  to  hear  the  sound  from  the  ambulance 

1 .3. 1 .2  The  physician  shall  be  able  to  record  the  sound  from  the  ambulance 

1 .3.1.3  The  physician  shall  be  able  to  speak  to  the  people  in  the  ambulance 

1 .3.1 .4  The  sound  implementation  shall  be  full  duplex 

1 .4  Vitals  Display 

1 .4. 1  Show  Patients  vitals  signs  in  real  time 

1 .4. 1 . 1  Electrocardiogram,  leads  selectable  by  physician  or  paramedic 

1 .4. 1 .2  Pulse  oximetry  waveform  and  digital  information  breathing  rate 

1 .4. 1 .3  Arterial  blood  pressure,  by  waveform  or  digital  display  or  systolic,  diastolic  and  mean  pressures 

1 .4. 1 .4  Respiratory  rate  (and  optional  waveform) 

1 .4. 1 .5  Core  body  temperature 

1 .4. 1 .6  Electronic  stethoscope  wave  display 

1 .4.2  The  physician  shall  be  able  to  pause  the  vitals  sign  readout 

1.5  Mapping  Display 

1.5.1  Provide  a  map  with  the  ambulance  displayed  at  the  current  location 

1 .5.2  Provide  estimated  time  of  arrival 


2,  DEMS  Paramedic’s  functional  area 

2,1  Automated  Emergency  Run  Record  Management 

2.1.1  Provide  the  paramedic  with  an  outline  emergency  run  record 

2.1.2  .  The  run  record  shall  be  able  to  be  updated  by  querying  the  hospital  database 

2. 1 .3  Run  records  created  and  modified  in  this  panel  are  automatically  transferred  to  the  Physician  workstation 

2. 1 .4  Provide  5  sub-pages  for  entering  information 
2, 1.4.1  On-Scene: 

2,1. 4. 1,1 


Shows  patient  information  and  information  about  the  scene  and  the  situation  of  the 
emergency 

Provide  the  ability  to  swipe  a  driver’s  license  for  patient  information  input 
The  paramedic  will  be  able  to  switch  between  patients*  forms 
The  physician  will  be  restricted  to  read-only  viewing  of  the  run  records 

2. 1.4.2  Examination/Observation: 

2. 1 .4.2 .1  Will  contain  the  primary  survey  of  the  patient 
The  paramedic  shall  be  able  to  edit  the  fields  in  the  Examination/Observation  page 
Shows  a  picture  based  on  the  information  entered;  male,  female,  child,  infant 
The  paramedic  shall  be  able  to  identify  problem  areas  by  selecting  the  figure  and  description 
in  the  numbered  list 

2. 1.4.3  Patient  HX: 

2. 1 .4.3.1  Shows  the  background  history  of  the  patient 


2. 1.4. 1.2 

2. 1.4. 1.3 

2. 1.4. 1.4 


2.1. 4.2.2 

2.1. 4.2.3 
2.L4.2.4 
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2.1,43.2  Information  obtained  by  verbal  communication  with  the  patient  and  an  upload  of  the 
hospital ’s  database 

2. 1.4.4  Patient  TX: 

2.1.4.4.1  This  is  a  timestamp  log  of  all  medications  administered  to  the  patient 

2. 1 .4.4.2  Shows  what  was  given,  how  much  was  given,  and  when  it  was  given 

2. 1 .4.4.3  Shall  interface  with  a  bar  code  reader 

2. 1 .4.4.4  Shall  be  able  to  customize  the  display 

2. 1 .4.4.5  Shall  be  able  to  manually  set  the  administered  time 

2. 1 .4.4.6  Provide  area  for  documentation  or  comments 

2. 1.4.5  Narrative: 

2. 1 ,4.5,1  Provide  a  free- form  text  area  in  which  the  physician  can  view  the  narrative  details  of  the 
incident  scene,  transport,  treatment  and  treatment  response  of  the  patient 

2.2  Video  Display 

2.2. 1  Display  the  images  that  the  Physician  sees 

2.2.2  The  paramedics  shall  be  able  to  move  and  zoom  the  camera 

2.2.3  The  paramedics  shall  be  able  to  hear  the  physician  speak 

2.3  Vitals  Display 

2.3.1  Display  the  vitals  on  the  same  screen  as  the  video  display 

2.3.2  Show  patients  vitals  signs  in  real  time 

2.3.2. 1  Electrocardiogram,  leads  selectable  by  physician  or  paramedic 

2.3.2.2  Pulse  Oximetry  waveform  and  breathing  rate  digital  information 

2.5.2.3  Arterial  blood  pressure,  by  waveform  or  digital  display  or  systolic,  diastolic  and  mean  pressures 

23.2.4  Respiratory  rate  digital  display  (and  optional  waveform) 

23.2.5  Core  body  temperature 

23.2.6  Electronic  stethoscope  waveform  display 

2 .4  Emergency  Protocols 

2.4. 1  Accessible  through  the  vitals  display 

2.4.2  A  web-page-like  interface 

2.5  Mapping  and  Navigation  Interface 

2.5. 1  Obtain  position  via  GPS 

2.5.2  Provide  a  map  with  the  ambulance  displayed  at  the  current  location 

2.53  Provide  a  map  with  the  travel  route  to  the  destination 

2.5.4  Provide  estimated  time  of  arrival 

2.5.5  Provide  a  zoomed  map 

2.5.6  Provide  a  map  scrolled  in  a  specified  direction 

2.5.7  Clear  the  calculated  route  on  the  map 

2.5.8  Provide  information  on  landmarks  such  as  schools,  hospitals,  boundaries,  and  railroad  tracks 

2.5.9  Continually  read  GPS  positioning  data  and  update  the  vehicle’s  position  on  the  map  every  second 

2.5.10  Show  the  coordinates  of  any  point  specified  by  a  mouse  click,  which  is  called  geocoding 

2.5. 1 1  Searching  a  place  on  the  map  by  street  address  and/or  ZIP  code 

2.5.12  Finding  the  nearest  street  to  a  GPS  position  (longitude/latitude),  which  is  called  reverse  geocoding 

2.5. 1 3  Compatibility  with  other  map  formats 

2.5. 14  Display  maps  with  zooming,  panning,  and  scrolling  functions 

2.5. 1 5  Calculate  routes  and  estimate  travel  time 

2.5. 1 6  Add  point  and  shape  objects  on  the  map 

2.5.17  Report  route  and  estimated  travel  time  to  base  station  once  a  route  is  chosen 

2.5.18  Show  direction  of  heading 

2.6  Communications  Display 

2.6. 1  Be  able  to  view  and  modify  parameters  affecting  data  communication  to  the  hospital 

2.6.2  Provide  a  method  for  automatically  determining  available  bandwidth  and  reliability  of  communication 
mediums  at  all  times  and  coordinate  their  usage  so  as  to  maximize  successful  data  transmission 

2.6.3  Be  able  to  view  maximum  and  actual  throughput  values  of  the  commu  nication  mediums 

2.6.4  Be  able  to  change  communication  parameters 

2.6.5  Provide  troubleshooting  information  to  the  paramedics 

2.7  Run  Record  Report 
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2.7.1  Be  able  to  view  and  modify  time -insensitive  billing  and  insurance  information 

2.7.2  The  system  will  automatically  save  the  information  when  the  user  switches  to  a  new  page  and  at  a  timed 
interval 

2.7.3  The  data  wilt  be  sent  to  the  hospital  only  when  the  paramedic  explicitly  sends  the  information 

2.7.4  Provide  5  sub-pages  for  entering  information 

2.7.4. 1  Vital  Report 

2.7.4. 1 . 1  The  top  half  of  the  screen  will  show  the  following:  Incident  number.  Date,  Unit  number, 
patient  number.  Dispatch  time,  on-scene  time, ... 

2.7 .4. 1 .2  The  bottom  half  of  this  screen  will  be  reserved  for  viewing  historical  Propaq  vitals  data 

2.7.4.2  Billing: 

2J.4.2. 1  Will  contain  responsible  party  and  insurance  information  for  the  patient 

2.7.4.2.2  The  patient  information  is  automatically  filled  in 

2.7.4.3  Release: 

2.7.4.3.1  The  patient  can  acknowledge  that  medical  care  was  or  was  not  recommended  and  that  he/she 
is  denying  care 

2.7.43.2  This  information  will  be  used  for  legal  issues 

2.7.4.4  Transport/Crew: 

2.7 .4.4. 1  Contains  patient  transport  method,  authorizing  physician,  and  destination  of  the  patient 


2.7.4.S  Report: 

2.7.4.5.1  Will  enable  the  paramedic  to  preview  or  print  the  entire  run  record  or  only  selected  portions 
2-7.4. 5. 2  The  printout  will  contain  all  textual  data  and  images  from  the  selected  sections  in  a  modular 

and  concise  format 

2.7.4.5.3  Will  emulate  many  of  the  run  record  forms  in  use  today 

2.7 .4.5.4  Option  of  printing  at  the  hospital  or  onboard  the  DBMS  vehicle 
2.8  Training 

2.8. 1  Accessible  from  the  onboard  computer  in  the  ambulance 

2.8.2  Provide  emergency  procedure  training  of  emergency  personnel 

2.8.3  Utilize  2D  and  3D  illustrations,  video,  and  voice 

2.8.4  Provide  testing  and  feedback  to  provide  a  professional  curriculum  and  meet  national  standards  of  the 
Department  of  Transportation 

2.8.5  Provide  case  studies  of  real  emergency  calls 

2.8.6  Provide  an  on-line  medical  dictionary 

2.8.7  Available  at  any  time 


6.  DEMS  System  Development  Checklist 

The  list  that  follows  constitutes  a  checklist  of  tasks  and  documentation  that  must  be  completed  in  order 
to  bring  DREAMS/DEMS  to  a  successful  conclusion. 

1 .  DEMS  Definition 

The  Definition  Document  provides  a  broad  overview  of  the  system,  and  delineates  high  level 
requirements.  This  document  becomes  a  baseline  document,  designed  to  provide  guidance 
throughout  the  project.  The  elements  of  the  Definition  Document  are  shown  below  in  the  outline. 

1.1  Overview/Background 

Background  or  the  program,  including  historical  perspectives  that  will  aid  in  understanding 
the  course  of  the  program’s  evolution.  Overview  of  how  the  program  should  function  and 
integrate.  View  of  benefits  to  be  derived. 

1.2  Requirements  Summary 
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A  high-level  summary  of  key  requirements  that  must  be  met  in  order  for  the  program  to  be 
successful.  This  summary  is  not  devolved  to  the  level  of  detoil  of  the  specific  requirements 
associated  with  individual  subsystems  or  their  components. 

1.3  Subsystems 

A  description  of  die  subsystems  associated  with  the  program,  and  a  narrative  of  how  each 
will  inter-operate  and  function. 

1.3.1  Physician’s  Workstation  System 

1.3.2  Ambulance 

1.3.3  DTS  (Deployable  Telemedicine  System) 

1.3.4  Communications  Environment 

1.4  Project  Plan 

Delineation  of  how  the  project  shall  be  managed  administratively,  including  milestones, 
timelines,  roles  and  responsibilities,  periodic  programmatic  reviews,  and  methods  of 
managing  changes  mandated  in  the  process  of  review  and  completion 

1 .4. 1  Target  Deliverable  Systems 

1.4.2  Responsibilities 

1 .4.2. 1  Design  Review  Team(s) 

1. 4.2.2  Test  Teams 

1.4.3  Timeline 

1 .4.3.1  Design  Reviews 

1 .4.3 .2  Change  Management  System 

Deliverables 

This  document  identifies,  in  detail,  die  various  hardware,  software,  documentation  and  training 
elements  that  must  be  in  place  prior  to  system  delivery  and  acceptance.  The  specific  subsystems 
are  identified  and  further  delineated  by  their  hardware  and  software  components.  Interdependence 
between  subsystems  and  components  therein  shall  be  identified  by  an  interoperability  matrix.  This 
document  also  specifies  the  necessary  requirements  definitions  at  the  system,  subsystem  and 
component  levels  needed  for  the  overall  system  to  function  as  designed.  The  requirements  shall 
serve  as  a  means  to  judge  when  the  program  is  near,  and  at,  completion  (all  requirements  have  been 
addressed  in  the  various  components,  subsystems  and  overall  system).  Further,  system  (and 
subsystem)  testing,  requirements-driven,  shall  be  developed,  implemented,  and  satisfactorily 
completed  prior  to  delivery.  Discrepancies  discovered  in  testing  shall  be  addressed  and  any 
appropriate  corrective  steps  implemented.  Finally,  user  and  administrator  documentation  shall  be 
prepared  and  evaluated  to  establish  that  the  users  and  responsible  administrator  do  not  require 
constant  input  from  program  developers  to  operate  and  maintain  the  system. 

2. 1  Physician’s  Workstation  System 

2.1.1  Hardware 

2.1.2  Software 

2.2  Ambulance  System 

2.2.1  Hardware 

2.2.2  Software 

2.3  Deployable  Telemedicine  System  (DTS) 

2.3.1  Hardware 

2.3.2  Software 
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2.4  Communications  Environment 

2.5  Training 

A  training  plan  shall  be  developed  that  addresses  the  routine  and  administrative  operation  of 
the  system,  and  teaches  the  users  and  administrators  all  of  the  facilities  of  the  hardware  and 
software  that  may  be  encountered  in  “normal”  EMS  operation. 

2.6  Documentation 

2.6.1  System  Design  Document 

The  System  Design  Document  shall  be  an  overall  planning  document  that 
incorporates  System  Requirements  (high  level  requirements),  and  the  development 
process  required  to  achieve  these  requirements.  Administrative  planning  detail  is 
addressed  in  the  Definition  Document  (above)  and  shall  be  referenced  to  that 
document. 

2.6.2  Functional  Requirements  Document 

A  Functional  Requirement  Document  (  or  a  chapter  to  this  document)  shall  be 
prepared  for  each  Subsystem,  and  each  component  in  those  Subsystems,  specifying 
the  necessary  functionality  of  each  Subsystem  and  component.  These  Functional 
Requirements  shall  be  responsive,  and  referenced  to,  the  System- Level 
requirements;  more  specific  Functional  Requirements  may  be  identified  in  these 
sections  in  order  to  assure  the  correct  interoperation  of  the  Subsystems  in  forming 
the  System. 

2.6.2. 1  Physician’s  Workstation  System 

2.6.2.2  Ambulance 

2.6.2.3  DTS  (Deployable  Telemedicine  System) 

2.6.2.4  Communications  Environment 

2.6.3  Test  Plan 

A  Test  Plan  shall  be  developed  and  documented.  This  plan  shall  address  testing  and 
validation  using  several  methods.  Testing  shall  occur  in  at  least  two  facilities: 
Software  and  system  testing  shall  occur  in  College  Station,  at  the  Laboratory 
designed  for  this  work  in  Room  608Q  of  the  Blocker  Building  at  Texas  A&M 
University.  Medical  validation  testing,  and  additional  software  testing  shall  occur  at 
die  Institute  for  Biosciences  and  Technology,  in  Houston,  Texas.  Additional  testing 
may  be  carried  out  in  other,  potentially  remote  settings,  including  in  a  deployed 
facility  on  the  campus  of  Texas  A&M  University,  or  in  Liberty  County,  Texas,  under 
the  guidance  and  supervision  of  the  identified  responsible  party  for  such  testing. 

2.6.3. 1  Functional  Test  Plan 

Functional  testing  shall  be  developed,  documented  and  implemented  using  a 
scenario-based  approach  which  causes  operation  of  all  elements  of  he  system 
in  course  of  normal  operation,  and  further,  testing  shall  be  conducted  in  a 
linear  manner  that  assures  all  of  the  various  hardware  and  software 
components  available  are  evaluated  and  provide  the  expected  operation. 

Both  the  scenario -based  and  linear  testing  shall  be  referenced  back  to  specific 
requirements. 

2.6.3.2  Medical  Validation  Test  Plan 

Medical  validation  testing  shall  be  developed,  documented  and  conducted  to 
assure  that  the  operation  of  the  system  meets  the  requirements  of  such 
medical  knowledge,  protocols  and  procedures  as  needed  for  the  discharge  of 
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normal  operation.  All  medical  validation  testing  shall  be  referenced  back  to 
applicable  requirements.  Additional  medical  validation  testing  may  be 
developed,  documented,  and  implemented  to  facilitate  meeting  requirements 
for  certification  levied  by  other  organizations  and  agencies  (FDA,  etc.). 
2.6.33  College  Station  Test  Facility  (“608Q”) 

2.6.3.4  Houston  Test  Facility  (“IBT”) 

2.6.4  User  Guide 

User  Guide  documentation  shall  be  developed  to  serve  as  a  (quick)  reference  to 
operation  and  troubleshooting  of  the  system.  The  User  Guide  for  each  subsystem 
shall  be  directed  toward  the  normal  users.  Operation  of  each  subsystem  aid  each 
accessible  component  therein  shall  be  addressed. 

2.6.4. 1  Physician’s  System 

2.6.4.2  Ambulance 

2.6.4.3  DTS  (Deployable  Telemedicine  System) 

2.6.5  Administration  Reference 

An  administrator’s  reference  document  shall  be  developed  to  serve  as  a  detailed 
reference  for  the  administrator’s  use  in  configuring,  maintaining,  and  operating  the 
system.  Detailed  documentation  on  the  operation  and  function  of  the  components 
and  subsystems  shall  be  included,  with  the  goal  of  reducing  the  number  of  requests 
for  detailed  assistance  directed  to  the  developers. 

2.6.5. 1  Physician’s  System 

2.6.5.2  Ambulance 

2.6.5.3DTS  (Deployable  Telemedicine  System) 

7.  Summary  of  DEMS  Interagency  Interactions  (Policy  &  Procedures)  Specifications 
plus  Diagrams  -  Meeting  Notes 


TASK  1  -  Interagency  Interactions  (Policy  &  Procedure)  Specifications  +  Diagrams 
•  Defining  Requirements 

We  can  define  a  requirement  as  “  a  specification  of  what  should  be  implemented”. 


There  are  basically  two  types  of  requirements: 

•  functional  requirements  -  what  behavior  the  system  should  offer 

•  non-  functional  requirements  -  specific  property  or  constraint  on  the  system 


A  functional  requirement  is  a  statement  of  what  the  system  should  do  -  it  is  a  statement  of  system 
function 


NOTE:  Use  the  brainstorming  and  otherwise  design  notes  from  the  meetings  along  with  other 
sources  of  SOP  to  establish  and  document  system  requirements. 


Functional  requirement- what  the  system  should  do. 
Non-Functional  Requirement  —  a  constraint  on  the  system. 


82 


Step  1,  Find  (Identify)  Aetors  and  Use  Cases 

Step  2,  Detail  a  Use  Case 

Step  3.  Structure  the  Use  Case  Model 

NOTE  1 :  USE  CASE  MODELING  -  a  form  of  requirements  engineering 

Use  Case  Modeling  involves: 

1.  Find  the  system  boundary 

2.  Find  die  actors 

3.  Find  the  me  cases: 

a.  specify  the  use  case 

b.  create  scenarios 

The  output  from  the  use  case  modeling  activities  is  the  use  case  model.  There  are  four  components  of  this 
model: 

1 .  actors  -  roles  played  by  people  or  things  that  use  the  system; 

2.  the  cases  -  things  that  die  actors  can  do  with  the  system; 

3.  relationships  -  meaningful  relationships  between  actors  and  the  cases; 

4.  system  boundary  -  a  box  drawn  around  the  use  ernes  to  denote  the  edge  or  boundary  of  the 
system  being  modeled. 


Use  case  model  provides  a  prime  source  for 
objects  and  classes ,  It  is  the  primary  input  to 
class  modeling. 


Use  the  Meeting  Notes  (Liberty  County  EMS  and  June  26, 2002  College  Station)  along  with  other 
SOP  sources  to  establish  Use  Case  and  consequently: 

a)  Find  the  system  boundary 

b)  Find(Identify)  Actors 

c)  Find  Use  Cases 

•  specify  the  use  case 

•  create  scenarios 

The  System  Boundary  is  defined  by  who  or  what  uses  the  system  (DREAMS)  (i.e.  the  actors)  and 
what  specific  benefits  DREAMS  offers  to  those  actors  (i.e.  Use  Cases). 

Identify  and  Diagram  Use  Case(s) 
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Needed  Information  for  Use  Case  Identification  and  Modeling: 

1 .  Name  of  System  -  Digital  Emergency  Medical  Service  (DEMS) 

2.  List  of  Actors  - 

a)  EMT 

b)  Driver 

c)  Physician  (Physician  Workstation  at  Herman  Hospital) 

d)  Dispatcher  (Liberty  County  Emergency  Medical  Service) 

3.  Identify  DEMS  Use  Case(s) 

Questions  to  identify  use  cases: 

a)  What  functions  will  a  specific  actor  want  from  DEMS? 

b)  Does  the  system  store  and  retrieve  information?  If  so,  which  actors  trigger 
this  behavior? 

c)  Are  any  actors  notified  when  the  system  changes  state? 

d)  Are  there  any  external  events  that  affect  DEMS?  What  notifies  the  system 
about  those  events? 
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Re-write/update  of  Liberty  County  EMS  Meeting  Notes 
NOTE:  These  notes  supports  the  development  of  the  DEMS  Use  Case  Model 
BEGIN  SHIFT 

Boot  up  issues 

Stop  Unit  (DEMS)  EVERY  Stop 

•  time:  1.5  minutes  until  up 

•  shut  down  cycle:  3  minutes 

•  power  up:  power  boot  scripting,  to  bring  OS  and  DEMS  system  up 

•  power  controller  may  lengthen  time  to  be  ready  to  use 

Login:  Shift  start.  In  back  4  medics,  2  in  and  2  out 

•  at  card  swipe  =>  login/logout  screen 

•  card  +  PIN  =>  x  2  crew  members 

For  Individual  Run:  Medics  already  logged  in 

•  new  record/patient  pull  down  menu:  choose  name,  enter  PIN 
+ “card” 

•  change  initial  signature  if  patient  condition  changes 

Mirroring  information  to  Medic  not  with  patient  FYI 
SOP:  cards  MUST  be  carried 

SOP:  COMPLETE  ALL  RECORDS  BEFORE  SHIFT  LOGOFF 


INCIDENT 
Call  -  Pager  goes  off 
Unitoff 

1 .  Key  truck,  generator  on 
Magic  Button  -  Start  DEMS 

2.  Drivers  Station  to  map/GPS  -  allow  input  of  destination  and 
Dispatch  time 

3.  Back  comes  to  blank  Run  report 

Non-normal  Shut  Down  Restart: 

Blank  Record?  Or  Lost  Record? 

Barcode  scan 


86 


DISPATCH 


Riding  Medic  enters 
Destination 

Drive  en-route 

Hit  en-route  button 


AT  SCENE 

Log  time  on  scene 
Mileage 

Grab:  Drug  bags,  propaq,  and  gurney 
Get  Patient: 

Treat  Patient  in  place 
Take  back  to  ambulance 
Load  into  ambulance 


PATIENT  IN  AMBULANCE 

Sign  patient  refusals  (paper  only) 

Propaq  on  patient 

Hook  into  vehicle 
Lead  Medic  Signs  in: 

Barcode/pswd 

Start,  modify,  view: 

Patient  record 

Patient  Treated: 

IV,  O2,  blood,  airway 

Call  Life  Flight,  medcon  (medical  control) 


EN  ROUTE 

Enroute  time 
Mileage 


Continue  treatment  /  monitoring 
Update  patient  information 
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DESTINATIONS 


1.  Community  (no  calls  to  HH) 

a.  HH  contact  =>  transport  to  community 

2.  HH  by  ground 

3.  HHLF 

4.  Life  Flight  to  other  Hospital 


INCOMPLETE  RECORDS 

Automatic  Sync: 

At  Physician  work  station 
Every  time  it’s  available 


HOSPITAL/LZ(Loading  Zone  if  Life  Flight) 

Time  Out  at  H  /  LZ  (transfer  of  patient  time) 

Mileage  at  H  /  LZ 

1 .  Transfer  to  hospital 

Complete  run  record 

Possibly  deferred 
la.  Transfer 

Complete 

Possibly  deferred  (to  Community  H  +  HH) 

2.  Transfer 
Complete  records 

3.  Transfer  “By  voice” 

Transfer  records  to  HH 
Complete  records 

4.  Transfer 
Complete 

Possibly  deferred  (to  Community  H  +  HH) 
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LIFE  FLIGHT 


On  Scene  time 
Leave  scene  time 


LOGOFF/SHIFT  CHANGE 

Swipe  card 

If  reports  finished 

Allow  logoff 

Reports  unfinished 

Prompt  to  complete 

Final  versions  of  reports  queue  to  transfer 

•  LCEMS  billing 

•  HH  medical 

•  Research  data  to  repository 

•  Community  hospital  medical 


Summary  of  Technical  Meeting 
Held  at  TEES,  2002-06-26 


Concepts  /  Data  Representation  /  Information  Model  Issues 

1 .  Patient  data  should  be  patient-encounter-centric  not  incident- centric.  This  means  that  we  will  have 
to  use  some  type  of  derivable  number  to  uniquely  identify  the  specific  patient  encounter 

2.  All  stored  data  must  support  full  audit  trails 

a.  Revision  number 

b.  Revision  time 

c.  Who  revised 

d.  Record  of  past  values  and  times 

3.  All  data  records  must  have  the  following 

a.  Unique  record  ID 

b.  Link  back  to  unique  patient  ID  &  incident  ID 

c.  Unique  name  and  code  to  define  each  concept  in  the  record 

d.  Value  (text,  integer,  float,  Boolean,  array  of  numbers,  code) 

e.  Clinical  Valid-From  timestamp  (time  the  value  was  obtained,  blood  sample  was  drawn, 
time  medication  was  given,  etc.) 

f  Clinical  Valid-Until  timestamp  (principally  used  for  tracking  edited  values) 

g.  System  Valid-From  timestamp  (time  record  was  committed  to  DB) 

h.  System  Valid-To  timestamp  (for  edited  value,  the  time  the  edit  was  committed) 
i  Revision  number 

j.  Data  authorization  ID  (ID  number  of  person/device  who  clinically  authorized  the  data) 

k.  Commit  authorization  ID  (ID  number  of  person  /  device  who  authorized  the  commit  to  the 
DB) 

4.  All  data  elements  must  be  cross-referenced  to  master  concept  data  dictionary 

5.  The  data  elements  present  on  the  Liberty  County  EMS  run  sheets  and  LCEMS  medical  protocols 
and  SOPs  will  be  used  as  the  source  for  the  concept  data  dictionary. 

6.  All  concepts  present  on  the  existing  LCEMS  run  sheets,  medical  protocols,  and  SOPs  will  be 
available  in  the  DEMS  EMT  Station  and  Physician  Station  software. 

7.  Functions  to  access  the  data  will  be  developed,  if  not  already  extant.  Both  basic  data  retrieval  and 
abstraction  functions  will  be  required. 

The  above  Issues  2-6  were  agreed  to  in  the  meeting.  Issue  1  came  up  after  the  meeting  adjourned 
during  the  review  of  Kevin  Gupton’s  database  diagram, 

UTHSCH  will  provide  to  TAMUS  a  data  dictionary  of  all  of  the  concepts  contained  in  the  LCEMS  run 
sheets,  medical  protocols,  and  SOPs.  Data  dictionary  will  include:  concept  id  number,  concept  name 
(short),  concept  name  (long),  concept  definition,  reference  name,  reference  name  source,  type  of  value 
(text,  integer,  float,  coded,  etc.),  normal,  abnormal,  critical,  and  absolute  ranges  (where  appropriate),  is  it  a 
repeated  measure,  and  the  units  of  measure  to  be  used  (where  appropriate). 
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UTHSCH  will  work  with  TAMUS  to  create  one  or  more  information  models  to  represent  the  clinical  and 
non-clinical  information  about  each  patient  care  encounter  (this  includes  the  incident  information,  vehicle 
information,  administrative  information,  and  patient-care  information).  These  information  models  will  be 
used  to  instantiate  a  database,  provide  an  intellectual  model  for  use  when  designing  and  discussing  patient 
care  and  clinical  decision  support,  provide  a  foundation  for  data  interchange  functions. 

TAMUS  will  instantiate  the  data  model  in  a  manner  that  meets  the  clinical  data  needs  of  the  physicians, 
EMTs,  and  provider-extenders  (e.g.,  medical  protocols).  Instantiation  may  be  in  the  form  of  a  database. 

TAMUS  will  develop  APIs  to  the  instantiated  data  model  to  meet  the  medical  data  storage  and  retrieval 
needs.  UTHSCH  will  provide  a  list  of  the  needed  functions. 

“Birth  and  Death  of  Data” 

A  long  discussion  about  the  birth  and  death  of  data  resulted  in  the  following  agreements. 

1 .  During  a  patient  treatment  /  transport  encounter  (“ambulance  run”),  the  authoritative  record  of  the 
patient  encounter  exists  on-board  the  ambulance.  This  is  a  working  copy  of  the  encounter  record. 

2.  One  or  more  partial  or  complete  working  copies  may  exist  in  other  locations  such  as  the  physician’s 
workstation,  the  receiving  facilities  emergency  department,  or  the  emergency  medical  service’s 
office 

3.  Once  a  record  has  been  “signed”  for  closure  on-board  the  ambulance,  no  further  edits  may  be  made 
to  the  record.  Once  signed  the  record  is  marked  “signed”  and  is  tagged  for  upload  to  the  master 
authoritative  data  repository  at  the  emergency  medical  service’s  office. 

4.  The  medically  relevant  portions  of  the  encounter  record  will  be  extracted  into  an  HL7-compliant 
message,  encrypted,  and  transmitted  to  both  the  hospital  that  received  the  patient  and  the  hospital 
where  the  physician’s  workstation  is  located  (this  latter  process  only  occurs  when  a  mentoring 
request  occurs  during  the  treatment/transport). 

5.  Working  and  signed  encounter  records  may  be  maintained  on  the  ambulance  if  the  records  have 
either  not  been  completed  or  when  communications  pathways  to  upload  the  data  have  not  been 
available. 

6.  A  simplified  state  diagrams  for  the  transition  is  shown  in  table  1. 
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Table  1  State  Diagram  for  Encounter  Records 
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+  —  1  or  more,  *  ==  0  or  more,  0  ==  null  or  empty  set,  |  ==  selection  or  choice 

So  W+ 1 0  ==  one  or  more  working  encounter  records  or  no  records.  This  is  distinct  from  zero  or  more  working  encounter 
records. 

In  this  state  diagram,  any  previous  working  or  signed  records  are  ignored  from  the  “NewPatient”  state  on  down. 


Usability  Issues 

Much  discussion  about  how  to  distinguish  between  an  edit  and  a  new  record  event  and  how  to  “sign”  or 
authenticate  individual  data  elements  occurred.  As  a  first  pass,  we  agreed  that  a  “sign”  button  would  be 
added  to  each  page  or  section  of  the  charting  screens.  Data  elements  could  be  freely  edited  and  changed, 
but  the  “sign”  button  would  have  to  be  pressed  or  clicked  to  save  the  data.  Any  changes  to  signed  fields 
where  the  event  times  did  not  change  would  be  classified  as  an  edit.  Where  the  event  time  changed,  it 
would  be  classified  as  a  new  record.  We  still  need  to  work  on  how  to  do  some  of  the  event  times  behind 
the  scenes. 


Identifying  and  Modeling  Actors 


Name  of  System-  Digital  Emergency  Medical  Service  (DEMS) 

List  of  Actors  - 

e)  EMT  (EMTi) 

f)  Driver  (EMT2) 

g)  Physician  (0  or  More)  (Physician  Workstation  at  Herman  Hospital) 

h)  Dispatcher  (Liberty  County  Emergency  Medical  Service) 

Identify  Use  Case(s>  Emergency  Incident 

Identify  the  actors  by  considering  who  or  what  uses  the  system  (DEMS),  and  what  roles  they  play  in  their 
interactions  with  the  system. 

In  terms  of  modeling  actors,  remember  the  following  points: 


92 


•  Actors  are  always  external  to  the  system  -  they  are  outside  of  the  software 
Developer’s  control 

•  Actors  interact  directly  with  the  system  -  this  is  how  they  help  to  define  the  system 

boundary  — ~ 

•  Actor  represent  roles  that  people  and  things  play  in  relation  to  the  system,  not  specific 
people  or  specific  things 

•  One  person  or  thing  may  play  many  roles  in  relation  to  the  system  simultaneously  or  over 
time. 

•  Each  actor  must  have  a  short  description  (one  or  two  lines)  that  describes  what  this  actor  is 
from  a  business  perspective. 

•  Likes  classes,  actors  may  have  compartments  that  show  attributes  of  the  actor  and  events 
that  the  actor  may  receive. 

List  of  Actors  - 

i)  Crew  (EMTi) 

j)  Driver  (EMT2) 

k)  Physician  (0  or  More)  (Physician  Workstation  at  Herman  Hospital) 

l)  Dispatcher  (Liberty  County  Emergency  Medical  Service) 

Short  description  of  each  actor: 

EMTj :  Crew  EMT  on  Dispatched  Ambulance 
EMT2 :  EMT  that  drives  the  Dispatched  Ambulance 
Physician:  Emergency  Medical  Operations  Physician  On  Call 
At  Herman  Hospital 

Dispatcher:  Liberty  County  Emergency  Medical  Service  Dispatcher  On 
Duty 


Development  of  a  Candidate  List  of  Use  Cases 

Name  of  System  —  Digital  Emergency  Medical  System  (DEMS) 

List  of  Actors  - 

m)  EMT 

n)  Driver 

o)  Physician  (Physician  Workstation  at  Herman  Hospital) 

p)  Dispatcher  (Liberty  County  Emergency  Medical  Service) 

Identify  Use  Case(s)-Use  Casel  -  Emergency  Incident 

Use  Case2  - 
Use  Case3- 

The  best  way  of  identifying  use  cases  is  to  start  with  the  list  of  actors,  and  then  consider  how  each  actor  is 
going  to  use  the  system  (DEMS). 

Each  use  case  must  be  given  a  short,  descriptive  name  that  is  a  verb  phrase  -  after  all,  the  use  case  is  doing 
something! 
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CALLS  REPORTABLE  TO  LAW  ENFORCEMENT  AGENCIES 

(LCEMS  requirement) 


Employees  who  are  responding  to  a  call  that  may  need  law  enforcement 
involvement  such  as  gunshot  wounds,  stabbing,  or  other  acts  of  violence  should 
report  such  incidents  immediately  to  the  proper  authorities.  If  knowledge  of  a 
violent  scene  is  available  before  arriving  at  the  scene  the  employee's  should 
proceed  toward  the  scene  but  remain  at  a  safe  distance  until  notified  by  the  proper 
authorities  that  the  scene  is  secure.  Employees  should  ensure  that  all  responders 
remain  at  a  safe  distance  by  notifying  dispatcher  to  inform  all  responders  of  such 
until  proper  authorities  have  the  scene  secure.  Employees  should  ask  that  the 
authorities  remain  on  scene  until  patient  care  can  be  obtained  and  unit  leaves  the 
scene. 

Employees  responding  to  a  call  that  may  be  suspect  to  child  abuse  should 
notify  Child  Protective  Services  as  soon  as  possible.  In  the  event  that  they  are  not 
available  at  their  office  the  S.O.  has  a  schedule  of  on-call  workers  and  may  be 
asked  to  notify  available  persons  on  call  and  for  such  person  to  return  call  so  that 
the  incident  may  be  reported. 


SOP  -  Call  Reportable  to  Law  Enforcement 

Matt  —  Should  this  be  included  in  DEMS?? 

Laurie  —  Does  not  seem  to  alter  DEMS  activities! !  I 
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Minimum  Functional  Requirements  for  DEMS  Hardware  and  Software  Systems 

I.  DEMS  System  (General) 

a.  DEMS  installations  (an  installation  consists  of  either  an  ambulance  software/hardware 
package,  a  DTS,  a  rural  ER  hardware/software  package,  or  a  physician  workstation)  shall  be 
started  from  a  “cold”  (i.e.  hardware  and  turned  off)  state  with  a  single  button  push, 

b.  DEMS  installation  software  shall  be  restarted  if  necessary  from  a  single  application,  batch 
file,  or  shortcut 

c.  No  display  other  than  the  GUI  shall  be  presented  to  the  user  during  either  the  starting  or 
stopping  of  the  DEMS  software. 

d.  All  DEMS  software  shall  require  a  token  and  pin/password  or  two  token  authentication 
before  it  can  be  used. 

e.  All  DEMS  software  shall  support  multiple  simultaneously  logged  in  users  with  assigned 

roles  "  ° 

f.  All  DEMS  software  shall  support  multiple  simultaneously  logged  in  users  with  designations 
of  active  and  inactive 

g.  All  DEMS  software  shall  support  changing  the  currently  active  users  on  the  fly. 

h.  All  DEMS  software  shall  support  changing  the  roles  of  the  currently  active  users  on  the  fly 

i  After  patient  records  have  been  “signed”,  the  records  shall  be  queued  for  automatic 

transmission  to  a  base  station, 

j.  All  unsigned  and  not  currently  active  patient  records  shall  be  backed  up  to  a  base  station  if  a 
broadband  connection  to  the  base  station  is  available  once  all  signed  records  have  been 
transferred. 

k.  Unsigned  records  transferred  to  a  base  station  shall  be  maintained  until  a  signed  record  is 
transmitted  to  the  base  station, 

L  DEMS  systems  shall  support  the  reloading  of  unsigned  records  into  remote  systems  (non¬ 
physician  workstation  units)  from  the  base  station  in  the  case  of  catastrophic  storage  failure 
on  the  remote  stations. 

m.  The  authoritative  copy  of  the  patient  record  shall  be  the  copy  on  the  remote  system  until  the 
record  is  signed,  transmitted,  and  acknowledged  by  a  base  station. 

a  Once  a  patient  record  has  been  signed  and  successfully  transferred  to  a  base  station,  the 
authoritative  copy  of  the  record  shall  be  the  copy  at  the  base  station. 

o.  Once  the  authoritative  copy  of  a  patient  record  has  been  transferred  to  a  base  station,  a  copy 
shall  be  maintained  on  the  remote  system  for  a  period  not  to  exceed  48  hours.  This  will  help 
insure  against  data  loss  due  to  catastrophic  failure  of  base  station  computer  hardware. 

p.  Base  station  computer  hardware  shall  contain  hardware  RAID  or  other  hardware-based  hard 
drive  mirroring 

q.  Base  station  computer  hardware  shall  support  scheduled,  automated  baclop  systems, 

II.  Concepts  /  Data  /  Information 

a.  Patient  data  shall  be  patient-encounter-centric  not  incident-centric. 

b.  All  stored  data  shall  support  full  audit  trails 

i  Revision  number 

ii.  Revision  time 

iii.  Who  revised 

iv.  Record  of  past  values  and  times 

c.  All  data  records  shall  have  the  following 
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i  Unique  record  ID 

ii.  Link  back  to  unique  patient  ID  &  incident  ID 

iii.  Unique  name  and  code  to  define  each  concept  in  the  record 

iv.  Value  (text,  integer,  float,  Boolean,  array  of  numbers,  code) 

v.  Clinical  Valid-From  timestamp  (time  the  value  was  obtained,  blood  sample  was 
drawn,  time  medication  was  given,  etc.) 

vi.  Clinical  Valid-Until  timestamp  (principally  used  for  tracking  edited  values) 

vii.  System  Valid-From  timestamp  (time  record  was  committed  to  DB) 

viii.  System  Valid-To  timestamp  (for  edited  value,  the  time  the  edit  was  committed) 

ix.  Revision  number 

x.  Data  authorization  ID  (ID  number  of  person/device  who  clinically  authorized  the 
data) 

xi.  Commit  authorization  ID  (ID  number  of  person  /  device  who  authorized  the  commit 
to  the  DB) 

d.  All  data  elements  shall  be  cross-referenced  to  master  concept  data  dictionary 

e.  All  concepts  present  on  the  existing  LCEMS  run  sheets,  medical  protocols,  and  SOPs  will 
be  available  in  the  DEMS  EMT  Station  and  Physician  Station  software. 

£  Functions  to  access  the  data  will  be  developed,  if  not  already  extant.  Both  basic  data 
retrieval  and  abstraction  functions  will  be  required. 

g.  A  clinical  data  dictionary  shall  be  created  that  includes  all  clinical  concepts  (data  elements) 
present  on  the  Liberty  County  EMS  run  sheets,  LCEMS  medical  protocols  and  SOPs. 

h.  The  data  dictionary  of  concept  definitions  will  define  the  following: 

i  Concept  name 

ii.  Concept  number 

iii.  Concept  definition 

iv.  Data  type  -  coded,  numeric,  text,  Boolean,  etc. 

v.  Units,  if  appropriate 

vi.  Reference  ranges  -  ‘normal’,  abnormal,  critical,  absolute 

vii.  Valid  codes,  if  concept  is  a  coded  value 

i  The  data  dictionary  will  define  concepts  as  they  are  represented  clinically.  Physical  storage 
of  the  data  values  for  the  concepts  may  be  in  alternate  forms  as  long  as  the  database  I/O 
routines  accept  and  return  data  using  the  appropriate  data  type, 
j.  DEMS  software  /  GUI  shall  support  both  creating  new  records  and  the  editing  of  existing 
records. 

III.  Usability 

a.  General  principles 

L  All  clinical  functions  of  system  must  be  operable  by  a  multiple 
modes  of  interface  (e.g.,  touchscreen  and  keyboard,  or 
touchscreen,  keyboard,  and  tablet) 

ii.  All  clinical  functions  must  be  fully  accessible  form  any  single 
input  device  with  simple,  one  button,  either  keyboard  or  mouse, 
access  (i.e.,  no  “shift-click”  or  “Ctrl- alt-right  click”  combinations 
for  clinical  functions.) 

iii.  Purely  technical  commands,  such  as  checking  status  of  power 
Controller,  may  have  access  limited  by  using  key  chords. 

iv.  Information  and  data  presented  to  clinical  users  musts  be  presented 
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in  a  manner  that  is  similar,  if  not  identical,  to  the  manner  that  is 
routinely  presented  to  them.  For  example:  blood  pressure  should 
be  represented  as  “120/70”  no  “SBP:  120,  DBP:70”. 
v.  Information  and  data  presented  to  clinical  users  must  be  presented 
in  a  manner  that  allows  clinical  users  to  recognize  important  data. 

b.  More  detoils  to  follow  based  on  the  SHIS  evaluation  and  feedback  from 
physicians. 


Questions  to  Answer  for  Liberty  County  Deployment 

How  is  a  physician  (at  Herman)  notified  when  assistance  is  required  by 
Ambulance? 

Where  does  the  emergency  run-record  end  up? 

•  Does  it  end  up  as  a  paper  copy  to  file?  Soft  Copy? 

•  Does  the  physician  need  to  write  to  it?  (he  currently  can’t) 

•  If  so,  does  the  hospital  record  need  to  synch  to  ambulance? 

•  Where  does  the  stripped  down  (no  patient  indicators)  run  record  get  stored 
for  further  processing? 

•  How  does  this  database  get  created? 

•  Only  found  on  ambulance?  Hospital?  Both? 

•  Are  refusal  records  also  stored? 

•  If  remote  physician  is  not  needed  anymore,  doe  additions  to  the  run-record 
Need  to  be  synched  with  record  at  hospital? 

When  does  the  local  database  get  accessed?  When  the  run  record  is  created? 
Finished?  All  the  time? 

What  other  information  (apart  from  run  record  info)  needs  to  be  stored  in  the 
database? 

•  Vital  Signs?  (All  or  6  second  chunks) 

How  will  video  get  stored? 

How  do  paramedics  initiate  the  system? 

•  How  do  they  log  into  the  system? 

•  How  are  their  “signatures”  attached  to  procedures  on  the  patient. 

How  do  paramedics  log  out  of  the  system? 

•  How  is  the  system  shut  down? 

Should  the  physician  determine  and  tell  the  system  how  much  communication 
resources  he  requires?  (e.g.  Does  the  physician  need  to  tell  the  system  that  he 
needs  video?  Audio?  Etc.? 

Are  wearable  computers  to  be  deployed? 

•  What  functionality  will  they  support? 

How  do  we  match  vital  signs  from  the  monitor  to  a  patient  when  there  are  more 
than  one(l)  patient  on  the  ambulance? 

When  system  loses  connection,  how  is  it  reestablished  to  Hospital? 

•  Re-sending  notification?  Automatically? 

Is  the  web  training  system  to  be  included? 
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DREAMS  Actors 


Dispatcher 

Patient 

Lead  Medic 
(Paramedic) 

Subordinate  Medic(s) 
(Basic  or  Intermediate) 

Doctor  at  Hospital 

Receiving  Physician 


*  Administrators 
-EMT 


-  Workstation  hospital 

-  Receiving  Hospital 
Systems  Administrator 


Researchers 


DREAMS  Transport  Options 


• 

PATIENT  REFUSAL  OF 
TRANSPORT 

* 

* 

Less  than  urgent  injury  —  Community  Hospital 
Emergency  injury  —  Community  Hospital 

• 

PATIENT  REFUSAL  OF 
MEDICATIONS 

* 

Emergency  Injury  —  Tertiaiy  Care  Facility 

(Life  Flight  not  available) 

* 

Emergency  Injury  —  Life  Flight  (on  scene) 

* 

Emergency  injury  Life  Flight  (rendezvous) 

• 

Patient  transfer 

• 

Triage 

Note:  Administrator  list:  Mileage  (validity) 
In  /  Out  service 
Inventory 
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DREAMS 


*  Types  of  Injuries  * 

-Routine 

-  Urgent 

-  Emergent 

•  Other 

-  Scan  Driver’s  License 

-  Modify  or  Add  New 

-  Test  group  w/Smart 
Cards 

-  2D  Bar  Code 

-  Printer 


DREAMS  Specific 

-  Request  Trauma 
Support  Physician 

-  What  if  we  have 
designated  comm  zone? 

-  Contingencies  [SOP] 

-  Triage 


DREAMS  Ambulance  Procedures 

Start  Ambulance  e=*> 

-  boot  system 

-  wash  vehicle 

-  shift  briefing 

*  system  check 


Start  Shift 

*  log  into  system 

-  check  truck  (vehicle) 

-  check  equipment 

check  medications  (inventory) 


may  want 
^  to  add  to 
system 


Note:  *  DREAMS  specific 


■©>  Pre -incident  Activity  =C>  Coincident  Occurs^^  e=C> 

*  Web-based  training  (not  for  Liberty) 

-  staff  meetings 

-  administration  staff 

*  communication  check 
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2>  Vehicle  Dispatch  b  . . 5> 

-  tone  received 

-  voice  report  (who,  what,  where) 

*  enter  navigation  information, 
calculate  route 

*  initiate  run  record** 


In  Route  to  Scene  ■  > 

-  dispatch  update 

*  medical  refresher 

*  initiate/update  rr** 


Note:  **  can  be  done  at  other  stage  s 


DREAMS  Ambulance  Procedures(continued) 


C^Arrival  at  Scene~~~^) 


^  On  Site  Treatment 


*  time  stamp 


(^Refusal 


-  take  equipment  to  patient 

-  scene  safety 

-  patient  evaluation 

-  patient  treatment 

*  initiate  DREAMS  call 

*  activate  wearable  computer 
(Xybernaut) 

*  initiate/update  run  record 


*  document  refusal 

*  finalize  run  record  (w/signature) 


-  call  Life  Flight 


Patient  on  Board 


*  Initiate/update  run  record 

use  driver’s  license 

*  initiate  DREAMS  call 

*  turn  off  wearable  computer 
-  treat/stabilize  patient 

*  move  to  communication  zone  (maybe) 

*  plug  in  V/S 

*  extract  patient  information  on  ZD 
bar  code  care?? 

*  call  Life  Flight 


Route  to  Hospital 


*  time  stamp  (leave  scene) 

*  treat/stabilize  patient 

*  initiate  DREAMS  call 

*  update  run  record 

-  contact  receiving  hospital 
*.  call  Life  Flight 


(^^Helicopter  on  Scent 


.may  go  to  helicopter 
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DREAMS  Ambulance  Procedures(continued) 


(^Arrival  at  HospjtaT^f  g> 


Patient  Moved  into  Hospital 


O 


*  timestamp 


-  transfer  patient  (control  &  patient) 

-  verbal  debriefing 

*  data  transfer 

-  print  out  run  record? 

*  terminate  DREAMS  call 

^  *  close  run  record  (if  complete  &  if  time) 


Helicopter  crew  takes  patient 


Emergency  Vehicle  Recovery  c==g> 

*  data  transfer 

*  finish  &  close  run  report  (if  time) 

-  clean  vehicle 

-  restock 

-  go  into  service  (if  in  area) 


Leave  Hospital  = 

-  go  into  service 

*  finish  ran  report  (if  time) 

*  web-based  training 

may  go  to  next  call 


<2 


Arrive  at  Station 


Shift  END 

*  timestamp 

*  finish  run  record 

&  transfer  data 

*  system  shutdown 

*  system  check 
-  debriefing 


Update  Briefing  from  Out-going  Crew 
Perform  Radio  Check  with  Dispatch 
Check  Truck 

Check  Standard  Medical  Equipment 
Boot  System 

•  Crew  Log  into  System  for  Run  Record 

•  Verify  Protocols  are  Operational 

•  Run  Propaq  Diagnostic 

•  Initialize  Connection  with  Hospital 

•  Verify  Video  Transmission  and  Camera  Operation 

•  Verify  Audio  Transmission  and  Clarity 

•  Verify  G.P.S.  Program  Operational 
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List  of  Use  Case  Scenarios 
(Short  Descriptive  Name  that  is  a  verb  phrase) 


1.  Emergency  Response(ER)  to  Chest  Pain  (ER_ChestPain) 

(business  or  home)  =>  local  community  hospital  for  stabilizing) 

2.  Emergency  Response(ER)  to  Slip  &  Fall  (ER_SIip&FalI) 

(broken  leg  -  simple  fracture) 

3.  Emergency  Response(ER)  to  Industrial  Accident  (ER_IndustrialAccident ) 

4.  Emergency  Response  (ER)  to  Automobile  Accident  (ER_AutoAccident) 

(2  Patients  both  trauma  -  die  within  an  hour) 

5.  Emergency  Response  (ER)  to  Acts  of  Violence  (ER_Acts-of- Violence) 
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8.  DEMS  UML  Diagrams 


8.1  DEMS  State  Diagrams 

Digital  Emergency  Medical  System  (DEMS) 


8.2  DEMS  Use  Case  Diagrams 

Use  case  diagrams  are  developed  for  the  two  actors  interacting  with  DEMS; 

a.  EMT(s) 

b.  Physician  Workstation  H-H 

8.2.1  EMT  Use  Case  Diagram 
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Bankim  Data 


Ill 


8.3  DEMS  Use  Case  Specifications 

8.3.1  DEMS  Use  Case  Specifications  for  Actor  Physician  Workstation  H-H 


_ Use  Case:  Manage  Patient  Run  Record 

ID: _ _ 

Actor(s): 

Physician  Workstation  H-H 
EMT 


Preconditions: 

1 .  EMT  initiate  Run  Record  upon  arrival  On  Scene 

2.  EMT  transmit  Run  Record  (Request  Assistance) 

3.  DEMS  operational 

Flow  of  Events: 

1 .  The  Use  Case  starts  when  the  “Run  Record”  (On  Scene  Page,  Exam  Observation  Page,  etc.) 
arrives  at  the  Physician  Workstation  H-H  “Interact”  Window.  Physician  press  the  “On-Scene” 
button.  Physician  selects  “Run  Record”  button, 

2.  DEMS  displays  the  run  record. 

3.  The  Physician  selects  patient  for  observation  from  a  list  of  patients  currently  stored  in  DEMS 

3.1  The  Physician  press  a  small  arrow  button  on  the  border  of  the  “Interact”  Window 

3.2  Physician  selects  patient  from  pop  -up  list 

4.  Physician  chooses  the  patient’s  forms  (Exam  Observation,  Patient  HX,  etc.) 

5.  DEMS  displays  the  form  corresponding  to  the  selected  tab  with  updated  information 

6.  If  the  Physician  selects  the  Narrative  tab  and  enters  information  in  the  form 
6, 1  DEMS  accepts  the  information  entered  by  the  Physician 

7.  Telestrator  function  relayed  to  EMT  station  and  not  stored. 

Postconditions:  — - 


Use  Case:  Control  Video  Camera 
ID: 


Actor(s): 

Physician  Workstation  H-H 
Video  Camera  System 


Preconditions:  DEMS  Started 
Flow  of  Events: 

1.  The  Use  Case  starts  when  Physician  select  video/vitals  button 

2.  DEMS  display  camera  view  and  camera  control  buttons 

2 . 1  Physician  select  camera 

2.2  DEMS  indicate  which  camera  selected 

3.  Physician  selects  direction/zoom  buttons  to  orient/zoom  camera 

4.  DEMS  orient/zoom  the  camera  accordingly  and  displays  view 

Issues:  Bandwidth  =>  Frame  rate;  “Quality”  ....  Or  video/stills 
“Physician  override  or  data  priority” 


Postconditions: 

1 .  The  selected  camera  positioned 
according  to  Physician’s  selections 


Use  Case:  View  Video  Images 


ID: _ 

Actor(s): 

Physician  Workstation  H-H 
EMT 

Preconditions: 

L  Sufficient  Bandwidth 


Flow  of  Events: 

1.  This  use  case  start  when  Physician 
selects  video/vitals  button 

2.  Physician  selects  “camera 
control’*  button 

2.1  DEMS  provides  full  rotation 
control  of  cameras  to  view 
different  video  aspects  of 
patient 

3,  Physician  selects  “zoom 
control”  button 

3.1  DEMS  provides  full  zoom 
control  of  cameras  to  view 
different  video  aspects  of 
patient 

4,  DBMS  provides  Physician’s-Eye 
view  of  a  patient  in  the  Interact™ 
Ambulance 

Postconditions: 

1.  DEMS  display  the  view  Physician 

selects 


Use  Case:  Listen  to  Audio 


Use  Case:  View  Real-Time  Data- Vitals 
ID: 

Actor(s): 

Physician  Workstation  H-H 
EMT 

Precondition:  EMT  connects  Propaq  Vitals 
Sign  Monitor  enabling  real-time  patient  vitals 
sign  display,  monitoring  and  transmission 

Flow  of  Events: 

1 ,  This  Use  Case  begins  wh  en  Physician 
selects  video/vitals  button 

2,  OEMS  displays  the  “Exam/Observation” 
Page  containing 

2.1  ECG  real-time 

2.1.1  Physician  Select  Leads 

2.2  Pulse  oximetry  waveform  real-time 

2.3  Breathing  rate  digitally 

2.4  Arterial  blood  pressure 

2.4. 1  Arterial  blood  pressure 
waveform/digital 

2.5  Respiratory  rate  digitally/waveform 

2.6  Core  body  temperature 

2.7  Electronic  Stethoscope  waveform 

3,  DBMS  pause  vitals  signs  real-time 
display  at  Physician’s  request 

Postconditions:  ~ 

L  DBMS  displays  the  patient’s  vital  sign 
data  in  real-time 
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Use  Case:  View  Map  Information 


ID: 


Actor(s): 

Physician  Workstation  H-H 


Preconditions:  DEMS  operational,  G.P.S.  link 
active 


Flow  of  Events: 

1.  This  Use  Case  begins  when  the  Physician 
selects  the  Map  button 

2.  DEMS  display  a  Map  with  the  “Interact™” 
Ambulance  displayed  at  the  current  location 
and  G.P.S.  coordinates  within  30  seconds 

3.  DEMS  display  estimated  time  of  arrival 

4.  DEMS  displays  destination  address 

5.  DEMS  displays  the  recommended  route 
(available  but  normally  turned  off) 


Postconditions: 

1.  DEMS  displays  the  current  location  of 
ambulance  and  related  data 
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DBMS  Use  Case  Specifications  for  EMT(s) 


Use  Case:  Enter  Run  Record  Information 


ID: _ 

Actors:  EMT(s) 

Preconditions:  DBMS  operational  (on) 

Flow  of  events: 

1,  EMT  presses  Run  Record  button 

2,  OEMS  provides  EMT  with  an  online  new  Emergency 
run  record 

3,  DEMS  displays  newly  created  Run  Record 

4  DEMS  activate  link  to  hospital  database  facilitating 
run  record  update  via  database  query 
Optional:  May  also  contact  EMS  Provider  Database 

5,  DEMS  transfer  to  Physician  Workstation  H-H  all 
created  and  modified  Run  Records  automatically  (on 
a  time  interval  as  a  function  of  Bandwidth  quality) 
only  if  “Mentoring”  is  taking  place 

6,  DEMS  provides  EMT(s)  multiple  pages  (On-Scene, 
Exam/Observation,  etc.)  for  entering  information 

7,  EMT  selects  tab  for  which  he  wants  to  enter 
information 

8,  DEMS  displays  form  corresponding  to  selected  tab 

9,  EMT  enters  information  in  form  displayed 
(Keyboard,  Mouse,  Touchscreen,  Signature  Pad, 
Magnetic  Stripe  Recorder,  etc,) 

Alternative  flow: 

1 ,  EMT  selects  run  record 

2,  DEMS  open  selected  run  record  for  editing 

3,  EMT  selects  tab  to  enter  information 

4,  DEMS  displays  form  corresponding  to  selected  tab 

5,  EMT  enters  information  in  form  displayed 

Postconditions:  ~  ~~  ~ 

1.  Patient  information  in  run  record 
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Use  Case:  Input  Patient  Data 

ID: _ 

Actors: 

EMT(s) 

Preconditions: 

1.  Card  reader  functional  and 
connected  to  DBMS 

2.  Run  Record  Open 

Flow  of  events: 

L  EMT  swipes  the  patient’s  driver 
license  through  Card  Reader 

2.  Card  Reader  reads  driver  license 

3.  Card  Reader  transfers  drivers  license 
information  to  DEMS 

Alternate  Flow  of  Events: 

L  Power  goes  out 

2,  Manual  entry  of  available  data 

Postconditions: 

1.  Run  Record  Fields  populated  by 
information  read  from  patient’s 
Drivers  License 


Use  Case:  Transmit  Run  Record  Information 
(For  Mentoring) 

ID:  ~ 

Actors: 

EMT(s) 

Transmission  System 
Preconditions: 

1 .  Transmission  link  up  and  secure 

2.  DEMS  operational 

Flow  of  events: 

1 .  EMT  presses  the  Send  button  on  the 
Run  Record 

2 ,  DEMS  sends  the  Run  Record  to  the 
Physician  Workstation  H-H 

Postconditions: 

1.  Run  Record  arrives  at  Physician 
Workstation  H-H 
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Use  Case;  Get  Patient  Vitals  Sign  Data 

ID: 

Actors: 

EMT(s) 

Vitals  Sign  Monitor/!  2 -Lead/other 

Preconditions: 

1 .  Patient  connected  to  Propaq  or  other 
monitor 

Flow  of  events:  " 

1 .  EMT  presses  the  V ideo/ Vitals  button 

2.  DEMS  displays  Patient’s  ECG 
rhythm  strip  (3-lead  or  12- lead  or 
other  waveform).  Pulse  Oximetry, 
Arterial  BP,  Respiratory  Rate,  Core 
Body  Temp,  Electronic  Sthetoscope 
Waveform  in  real-time 

Postconditions: 

1 .  Patient  Vitals  sign  data  displayed 


Use  Case:  Access  Emergency  Protocols 


1.  EMT  presses  Emergency  Protocols 
button 

2,  DEMS  displays  list  of  available 
protocols 

3.  EMT  selects  the  protocol  to  display 

4,  DEMS  displays  the  selected  protocol 

Postconditions: 

1 .  Emergency  Protocols  displayed 
(Later  version  will  walk  EMT 
through  protocols) 
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Use  Case:  Generate  Run  Record  Report 


ID: 


Actors: 

EMT(s) 

Preconditions: 


Flow  of  events:  ~ ~~~ 

1.  EMT  select  “Report”  button 

2.  DBMS  switch  the  screen  to  the  run  record  report  display 

3.  EMT,  in  the  top  half  of  the  screen,  observe  and  modify  the  values 

3. 1  Information  already  should  be  consistent  with  “On -Scene”  run 
record  values 

4  EMT  observe  the  lower  half  of  screen 

4  ,1  Historical  readings  from  patient  should  be  present 

4.2  EMT  navigates  presented  information 

5.  EMT  select  “Billing”  tab  on  top  of  screen 

6.  EMT  modify  available  fields 

6.1  Information  already  populated  should  be  consistent  with 
information  entered  in  the  “On-Scene”  run  record 

6.2  All  fields  should  be  modifiable 

7.  EMT  select  each  of  the  buttons  in  the  “Billing”  display  for  the  type 
of  payment 

7.1  DEMS  record  information  consistent  with  EMT(s)  selection  of 
the  type  of  payment 

8.  EMT  selects  the  “Release”  tab  at  the  top  of  the  page 

9.  Patient  enter  initials  in  the  top  boxes,  and  sign  and  date  at  the 
appropriate  location 

10.  DEMS  accept  the  patient’s  input 

1 1 .  EMT  sign  and  date  the  bottom  field 

11.1  DEMS  capture  and  retain  all  entered 
Information  for  future  use 

12.  EMT  select  the  “Transport/Crew”  tab  at  the  top  of  the  page 

13.  EMT  enters  correct  Information  in  provided  fields 

13.1  DEMS  capture  and  retain  all  entered 
information  for  future  use 

14.  EMT  select  the  “Report”  tab  located  at  the  top  of  the  page 

14. 1  DEMS  display  report  page 

1 5.  EMT  select  each  ele  ment  individually  to  be  print  previewed 

15.1  DEMS  display  a  print  preview  of  only  the  selected  element 

16.  EMT  select  each  element  to  be  printed 

16.1  DEMS  should  clearly  lay  out  the 
report  containing  only  the  selected 
element 

16.2  DEMS  print  preview  should  match  what  was  printed  on 
paper 

1 7.  EMT  select  printout  to  be  done  at  the  hospital 

17.1  DEMS  provides  printout  at  the  hospital 

1 8.  EMT  select  printout  to  be  done  on  the  ambulance 

18.1  DEMS  provides  printout  on  the  ambulance 


Postconditions: 


Use  Case:  Access  Training 
ID: 


Actors: 


Preconditions: 


Flow  of  events: 

1 ,  EMT  selects  the  Training  display 

1 . 1  DEMS  display  an  Index  of  available 
training  sessions 

2,  EMT  navigate  through  the  available  options 

3,  EMT  observes  what  is  available 

3. 1  DEMS  provides  2D  and  3D 
illustrations,  voice,  and  video 

3.2  DEMS  provides  an  option  for  feedback 
from  the  EMT 

3.3  DEMS  provides  case  studies  of  real 
emergency  calls 

3.4  DEMS  provide  an  easily  accessible  on¬ 
line  medical  dictionary 

3.5  DEMS  provides  options  to  be 

_ accessible  at  any  time  _ 

Postconditions: 


Use  Case:  Other? 


ID: 


Actors: 

DEMS  System  Engineer 
G,P.S. 


Preconditions: 


Flow  of  events: 

1.  DEMS  System  Engineer  upload  a 
new  map  for  the  navigation 

1 . 1  DEMS  should  accept  the  new 
map  and  it  should  work 
seamlessly  with  the  available 
system 

2,  DEMS  System  Engineer  upload 
new  map  of  a  different  file  format 
for  the  navigation  system 

2. 1  DEMS  uploads  the  new  map 

and  integrate  it  into  the  existing 
system  seamlessly _ 

Postconditions: 
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Trauma  Report  Form  Concepts-lncludes  the  concept  names,  datatypes,  and  descriptions  of  the  concepts  of  the  Trauma  Report  Form,  Code  definitions  are  defined  in  the  code  table. 
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APPENDIX  4,  Section  2:  DATA  DICTIONARY  CODE  ELEMENT  LIST 
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The  injury  of  the  patient  is  located  in  area  7 
defined  as '  area  below  the  horizontal  line  at 
the  level  of  umbilicus  to  to  the  line  joining  right 

superior  iliac  spine  and  pubic  symphysis,  in  Liberty  County  Trauma  Report 

Trauma  Informationjnjuryjnjury  Location__Area  7  supine  position  Form  Injury  Location  Diagram  140 
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The  injury  of  the  patient  is  located  in  area  19 

Trauma  Information JnjuryJnjury  Location_Area  defined  as  *  area  on  left  side  of  the  neck,  in  Liberty  County  Trauma  Report 

19  supine  position'  Form  Injury  Location  Diagram  140 
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Trauma  Informationjnjuryjnjury  Location_Area  The  injury  of  the  patient  is  located  in  area  29  Liberty  County  Trauma  Report 
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LIBERTY  COUNTY 
EMERGENCY  MEDICAL  SERVICE 

MEDICAL  PROTOCOLS 


•  Acute  Abdomen 

•  Anaphylactic  Reactions 

•  Altered  Mental  Status 

•  Childbirth 

•  Obstetrical  Complications 

•  Magnesium  Sulfate  Toxicity 

•  Dead  on  Scene 

•  Dehydration 

•  Hypothermia 

•  Heat  Exhaustion  /  Heat  Stroke 

•  Hypertension 

•  Hyperventilation 

•  Hypotension 

•  Medical  Unspecific 

•  Overdose  /  Poisoning 

•  Respiratory  Distress  non  Cardiac 

•  Seizures 

•  Stroke  (CVA) 

Return  to  Home  Page 


Chest  Pain 

Respiratory  Distress  Cardiac  Related 

Cardiogenic  Shock 

Asystole 

Bradycardia  /  A  V  Dissociation 
Pulseless  Electric  Activity  (PEA) 
Tachycardia  —  Stable 
Ventricular  Ectopy  /  PVC's 
Ventricular  Fibrillation 
Ventricular  Tachycardia 
Asystole  —  Tree 

Bradycardia  /  A  V  Dissociation  —  Tree 
Pulseless  Electrical  Activity  --  Tree 
Tachycardia  --  Tree 
Ventricular  Ectopy  /  PVC’s  —  Tree 
Ventricular  Fibrillation  --  Tree 
Ventricular  Tachycardia  —  Tree 
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LIBERTY  COUNTY 
EMERGENCY  MEDICAL  SERVICE 

PEDIATRICS  PROTOCOLS 

*  Neonate 

*  Guidelines  for  Pediatrics 

*  Pediatric  Arrest 

*  Pediatric  Medical  Unspecific 

*  Pediatric  Trauma 

Return  to  Home  Page  |  |  Medical  Protocols  I  f  Trauma  Protocols  |  Appendix 
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NEONATE 

BASIC  INTERVENTION 

•  Warm  and  prepare  isolate  prior  to  arrival. 

a.  Hypothermia  can  be  lethal 

b.  Maintain  a  thermo  neutral  environment 

•  Perform  primary  and  secondary  surveys. 

•  Establish  oxygen  therapy  as  required  by  patient’s  condition. 

a.  Ensure  proper  positioning  for  airway  control 

b.  Maintain  patent  airway 

c.  Use  proper  device 

ADVANCED  LIFE  SUPPORT 

INTERMEDIATE  INTERVENTION 

1.  Intubate,  if  needed 

2.  Establish  IV  of  NS  on  buritol  drip 

a.  At  60  80  ml/Kg/day  for  first  day  of  life 

b.  Requirements  usually  increase  approximately  10  ml/day  on 
subequent  days 

c.  Avoid  fluid  overload 

3.  Check  Dextro-stick. 

PARAMEDIC  INTERVENTION 

*  Apply  cardiac  monitor  and  obtain  strip. 

*  Special  situations  in  Neonatal  Transport: 

a.  Surfactant  deficiencies  and/or  pneumonia 

1.  Clear  airway  /  maintain  patency 

2.  Correct  body  positioning 

3.  Oxygenation 

b.  Pulmonary  air  leaks 

1.  Mild  needle  thoracentesis 

2.  Clear  airway  /  maintain  patency 

3.  Correct  body  positioning 

4.  Oxygenation 

c.  Cardiac 

1.  Different  between  cardiac  disease  vs  respiratory  disease 
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2.  Clear  airway  /  maintain  patency 

3.  Correct  body  positioning 

4.  Oxygenation 

5.  Treat  symptoms  of  failing  myocardium 

6.  Arrhythmia  protocols 

7.  Consider  hypoventilation  as  cause 
d.  Seizures 

1.  Establish  and  maintain  airway  as  needed 

2.  Oxygenation 

3.  Consider  Valium 

•  Always  consider  hypoxia  before  anything  else 

CONTACT  MEDICAL  CONTROL 
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GUIDELINES  FOR  PEDIATRICS 


GUIDELINES  FOR  PEDIATRICS 


AGE 

PULSE 

respirations! 

BP 

Neonate 

100  to  160 

40  to  60 

40  to  90  systolic 

20  to  60  diastolic 

6  months 

>100  to  160 

30  to  60 

80  to  106  systolic 
52  to  66  diastolic 

2  years 

>80  to  110 

24  to  40 

96  to  106  systolic 
52  to  66  diastolic 

7  years 

>65  to  110 

18  to  30 

96  to  112  systolic 
56  to  70  diastolic 

1 15  years 

11 . . 

j 

12  to  16 

llMW 

Device 

Infant 

8  to  1 1  kg 

12  to  14  kg! 

14  to  17  kg! 

18  to  23  kg  j 

24  to  30  kg 

j  02  Mask 

Newborn  j 

Pediatric 

Pediatric 

Pediatric  | 

Sbvm 

Infant  j 

Child 

Child 

[child 

OP  Airway] 

Infant 

Child 

Child 

Child 

mum 

pBH 

1 

2  1 

2 

| 

4.5 

5.0 

5.5 

£ 

IV  Cath  i 

>22  to  24  j 

18  to  22 

18  to  22 

BllllliH 
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PEDIATRIC  ARREST 

Pediatric  cardiac  and  trauma  arrest  should  be  treated  with  Adult  Algorithms  using 
the  following  drug  and  defibrillation  dosages. 

Pediatric  Code  Drugs 

•  Epinephrine  1: 10,000 

a.  Supplied  0.1  mg  /  cc 

b.  Dose  0.01  mg  /  kg 

•  Epinephrine  1:1000 

a.  Supplied  1  mg  /  cc 

b.  Dose  0.1  mg  /  kg 

•  Sodium  Bicarbonate 

a.  Supplied  1  mEq  /  cc 

b.  Dosage  lcc/ kg 

•  Atropine 

a.  Supplied  0.1  mg  /  cc 

b.  Dosage  0.02  mg  /  kg 

•  Lidocaine 

a.  Supplied  20  mg  /  cc 

b.  Dosage  1  mg/kg 

•  Narcan 

a.  Supplied  0.2  mg  /  cc 

b.  Dosage  0.02  mg  /  kg  minimum 

•  Valium 

a.  Supplied  5  mg  /  cc 

b.  Dosage  0.1  mg  /  kg 

•  Dextrose 

a.  Supplied  25  g  /  50  cc 

b.  Dosage  1  cc  /  kg 

•  Defibrillation 

a.  2-4  joules  per  kg  of  weight 


Standard  Weight  Estimates 


1  year  old  } 

3  year  old  |5  year  old 

8  year  old 

jlO  year  old 

10  kgs 

15  kgs  j[20  kgs 

25  kgs 

|30  kgs 
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PEDIATRIC  MEDICAL  -  UNSPECIFIC 

BASIC  INTERVENTION 

*  Perform  primary  and  secondary  surveys, 

*  Obtain  present  and  past  medical  history 

*  Obtain  temperature,  rectally  if  possible. 

*  Obtain  vital  signs. 

*  Administer  oxygen  therapy  as  dictated  by  patients  clinical  presentation 

ADVANCED  LIFE  SUPPORT 

INTERMEDIATE  INTERVENTION 

1.  Intubate,  if  needed 

2.  If  patient  shows  signs  of  hypotension  or  hypoperfusion,  establish  IV  of 
NS  with  buritrol,  titrated  to  maintain  normotension 

PARAMEDIC  INTERVENTION 

*  Apply  cardiac  monitor  and  obtain  strip. 

CONTACT  MEDICAL  CONTROL 

Standard  IV  Rates  for  Typical,  Non  Hypovolemic,  Pediatric  Patient 


[Age 

Weight  i 

Rate 

1 

10  kgs  j 

40  cc/hr 

l3 

15  kgs 

50cc/hr 

5 

20  kgs 

60  ec/hr 

25  kgs  j 

70  cc/hr  - 

|l° 

30  kgs 

75  cc/hr; 
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PEDIATRIC  TRAUMA 

BASIC  INTERVENTION 

•  Perform  primary  and  secondary  assessment 

•  Protect  the  cervical  spine,  immobilize  if  needed. 

•  Stop  all  life  threatening  bleeding 

•  Administer  high  flow  oxygen,  assist  respirations  with  BVM  if  needed. 

•  Obtain  vital  signs. 

•  Began  transport  if  patient  is  considered  ’’urgent”  or  ’’critical” 

ADVANCED  LIFE  SUPPORT 

INTERMEDIATE  INTERVENTION 

1.  Intubate,  if  needed 

2.  Establish  IV  of  LR,  titrate  to  maintain  a  normal  blood  pressure  for  the 
patient's  age  and  size.  Establish  a  second  IV  of  LR  if  patients  clinical 
presentation  or  mechanism  of  injury  justifies.  Use  a  buritrol.  May  use 
Saline  Lock. 

PARAMEDIC  INTERVENTION 

•  Apply  cardiac  monitor  and  obtain  strip. 

CONTACT  MEDICAL  CONTROL 
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LIBERTY  COUNTY 
EMERGENCY  MEDICAL  SERVICE 

TRAUMA  PROTOCOLS 

*  Amputations 

*  Bums 

*  Head  Injury  Isolated 

*  Maxillofacial  Injury 

*  Near  Drowning 

*  Snake  Bite 

*  Trauma 

Return  to  Home  Page  |  |  Medical  Protocols  I  i  Pediatric  Protocols  I  Appendix 
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AMPUTATIONS 

BASIC  INTERVENTION 

•  Perform  a  primary  and  secondary  survey. 

•  Control  hemorrhage  with  direct  pressure. 

•  Obtain  history  of  present  illness  and  past  medical  history 

a.  Time  of  amputation 

b.  Mechanism  of  amputation 

c.  Bystander  care  of  severed  part 

d.  Medication  usage 

•  Treat  other  urgent  injuries. 

•  Administer  oxygen  as  dictated  by  clinical  presentations. 

•  Treat  for  hemorrhagic  shock  if  necessary. 

•  Cover  amputated  part  with  sterile  gauze.  Moisten  with  normal  saline.  Next, 
cover  with  dry  dressing,  then  splint,  then  elevate. 

•  Place  severed  part  in  sterile  gauze,  Moisten  with  normal  saline  place  in  a 
water  tight  container,  and  pack  container  in  ice  but  do  not  freeze. 

•  If  partial  amputated,  dress  with  moist  gauze ,  splint  in  alignment  with 
extremities  to  ensure  optimum  blood  flow.  Avoid  torsion  when  handling 
amputated  part. 

•  If  amputated  extremity  and  profuse  bleeding  cannot  be  controlled  by  direct 
pressure,  elevation,  pressure  dressing,  or  pressure  point  contact  medical 
control  for  possible  application  of  a  tourniquet. 

ADVANCED  LIFE  SUPPORT 

INTERMEDIATE  INTERVENTION 

1.  Establish  Intravenous  Line  of  LR  and  titrate  to  systolic  blood  pressure 
of  100  mm  Hg.  If  amputation  is  to  an  extremity  and  time  permits,  start  a 
second  IV  of  LR. 

PARAMEDIC  INTERVENTION 

•  Apply  cardiac  monitor  and  obtain  strip. 

CONTACT  MEDICAL  CONTROL 
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BURNS 


BASIC  INTERVENTION 

*  Perform  a  primary  and  secondary  survey. 

*  Obtain  history  of  present  illness  and  past  medical  history 

a.  Cause  of  burn  (chemical,  thermal,  electrical,  etc.) 

b.  Length  of  exposure 

c.  Length  of  time  in  enclosed  compartment 

d.  Type  of  material  burning 

e.  Past  history  of  smoking,  CV  problems,  COPD 

f.  Bystander  treatment 

*  Administer  high  flow  oxygen  100%  humidified 

*  Suction  as  needed 

*  C  Spine  immobilization  if  not  cleared. 

*  Cover  affected  areas  with  dry  sterile  dressings/sheet.  If  chemical  exposure 
begin  decontamination  with  copious  amounts  of  water  or  saline. 

*  Treat  associated  fractures,  lacerations,  or  other  injuries. 

ADVANCED  LIFE  SUPPORT 

INTERMEDIATE  INTERVENTION 

1.  Intubate  early  if  any  respiratory  distress  or  if  needed 

2.  Establish  Intravenous  Line  of  LR  at  100  cc  per  hour  or  titrate  to  systolic 
blood  pressure  of  100  mm  Hg. 

Note:  The  goal  of  fluid  resuscitation  is  to  maintain  vital  organ  function 
while  avoiding  complications  of  inadequate  or  excessive  therapy. 

PARAMEDIC  INTERVENTION 

•  Apply  cardiac  monitor  and  obtain  strip. 

•  Administer  Morphine  2  to  6  mg  IV  for  severe  pain,  if  available. 

(Use  only  if  no  suspicion  of  respiratory  burns  or  associated  injuries) 

CONTACT  MEDICAL  CONTROL 
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HEAD  INJURY  -  ISOLATED 

BASIC  INTERVENTION 

•  Perform  primary  and  secondary  survey 

•  Oxygen  therapy  as  dictated  by  patient's  condition 

•  Cervical  spine  immobilization  unless  cleared. 

•  Monitor  vital  signs 

•  Transport  in  supine  or  30  degree  elevation  of  the  head,  if  not 
contraindicated. 

ADVANCED  LIFE  SUPPORT 

INTERMEDIATE  INTERVENTION 

1.  Intubated  if  needed. 

2.  IVofLRTKO 

PARAMEDIC  INTERVENTION 

•  Apply  cardiac  monitor  and  obtain  strip. 

•  Treat  hypotension  with  hypotension  protocol 

•  If  patient  presents  with  Glasgow  Coma  scale  of  <  8  and  with 
lateralizing  signs  (i.e.  weakness  to  one  side  or  unequal  pupils)  administer 
Mannitol  20%  1  2  gm/kg,  filtered  IV,  over  30  minutes. 

Note:  To  administer  mannitol  20%  you  must  use  a  Blood  Y  Tubing  for 
the  in  line  filter. 

•  Consider  mannitol,  as  above,  based  on  referral  center 
recommendations. 

CONTACT  MEDICAL  CONTROL 
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MAXILLOFACIAL  INJURY 

BASIC  INTERVENTION 

•  Perform  a  primary  and  secondary  survey. 

•  Oxygen  therapy  as  dictated  by  patient's  condition 

•  Vital  signs 

•  Spinal  immobilization  if  not  cleared. 

•  For  Orbital  or  Zygomatic  fractures  apply  loose  binocular  bandaging 

•  For  Nasal  Fractures  treat  epistaxis  by  direct  pressure  or  nasal  packing. 

•  Transport  in  semi  high  Fowler’s  or  higher  if  not  contraindicated. 

ADVANCED  LIFE  SUPPORT 

INTERMEDIATE  INTERVENTION 

1.  Intubate  if  needed,  must  be  direct  visualization  only 

2.  IVofLRTKO 

PARAMEDIC  INTERVENTION 

•  Apply  cardiac  monitor  and  obtain  strip. 

CONTACT  MEDICAL  CONTROL 
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NEAR  DROWNING 

BASIC  INTERVENTION 

•  Protect  the  Cervical  Spine  if  a  suspected  diving  injury  or  possibility  of 
impact  with  an  object. 

•  Remove  victim  from  the  water 

•  Perform  primary  and  secondary  survey. 

•  Obtain  history  of  present  illness  and  past  medical  history. 

•  Administer  high  flow  oxygen 

•  Obtain  and  record  vital  signs 

ADVANCED  LIFE  SUPPORT 

INTERMEDIATE  INTERVENTION 

1.  Intubated  if  needed. 

2.  Establish  IV  of  LRTKO. 

PARAMEDIC  INTERVENTION 

•  Apply  cardiac  monitor  and  obtain  strip. 

•  Treat  dysrhythmias  as  per  specific  protocol. 

CONTACT  MEDICAL  CONTROL 
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SNAKE  BITE 

BASIC  INTERVENTION 

•  Perform  primary  and  secondary  survey 

•  Obtain  information  on  snake  type  or  description  if  possible.  (If  possible 
bring  DEAD  snake  to  the  ED  for  positive  identification.) 

•  Obtain  vital  signs. 

•  Administer  oxygen  with  flow  and  device  being  dictated  by  patients  clinical 
presentation. 

•  IF  CORAL  SNAKE:  wash  wound  site  with  copious  amounts  of  water. 

•  Immobilize  affected  limb  with  splint  at  the  level  of  the  heart. 

•  Keep  patient  supine. 

•  Do  not  apply  ice,  cold  pack,  tourniquet  or  restriction  band. 

•  Call  poison  control  1  800  764  7661  if  bite  orenvenomation. 

ADVANCED  LIFE  SUPPORT 

INTERMEDIATE  INTERVENTION 

1.  Establish  IV  of  LR,  titrate  to  maintain  a  systolic  BP  of  100  mm  Hg. 
PARAMEDIC  INTERVENTION 

•  Apply  cardiac  monitor  and  obtain  strip. 

CONTACT  MEDICAL  CONTROL 


Page  188 


Appendix  6 


r* ;  • 

I- Home  Page 

k . - 


Trauma  Protocols 


TRAUMA 

BASIC  INTERVENTION 

•  Perform  primary  and  secondary  survey 

•  Obtain  history  of  present  illness  and  past  medical  history. 

a.  Mechanism  of  injury 

b.  Vehicle  speed 

c.  Seat  belt  use 

d.  Integrity  of  vehicle  compartment 

e.  Ballistics  information 

•  Maintain  airway  and  immobilize  the  cervical  spine. 

•  Treat  life  threatening  injuries. 

•  Monitor  the  vital  signs  every  5  10  minutes,  more  frequently  if  patient 
unstable. 

•  Administer  oxygen  as  indicted  by  patient  condition. 

•  Treat  if: 

a.  Aystolic  blood  pressure  less  than  100  mm  Hg  and  sign  and  symptoms  of 
shock  exist. 

b.  Suspected  blunt/penetrating  chest  or  abdominal  trauma  associated  with 
signs  and  symptoms  of  shock. 

c.  There  are  suspected  fractures  of  the  femur  or  pelvis. 

ADVANCED  LIFE  SUPPORT 

INTERMEDIATE  INTERVENTION 

1.  Intubate  where  appropriate. 

2.  Establish  two  IV' s  of  LR,  with  maxi-drip  tubing  and  large  bore  catheter. 

3.  Establish  second  IV  en  route  to  hospital. 

PARAMEDIC  INTERVENTION 

•  Apply  cardiac  monitor  and  obtain  strip. 

•  Consider  for  patients  with  isolated  long  bone  fractures,  otherwise 
hemodynamically  stable,  with  no  possibility  of  other  occult  injuries, 
morphine  sulfate  2  to  6  mg  IV,  titrated  for  effect. 

•  If  patient  is  combative  and  compromising  spinal  control,  consider 
administering  Diazepam  2  10  mg  slow  IVP  or  Versed  2  to  4  mg 
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(RULE  OUT  HYPOXIA  OR  SHOCK  AS  CAUSE  OF  AGITATION, 
MONITOR  RESPIRATIONS.) 

•  IF  patient  presents  with  definite  paralysis  from  spinal  injury  or  spinal 
shock  or  signs,  consider  Solumedrol  30  mg/kg  IV  drip  over  1  hr. 

CONTACT  MEDICAL  CONTROL 
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APPENDIX  A  -  Trauma  Score 


BASIC  INTERVENTION 

The  trauma  score  developed  by  Dr.  Champion  consists  of  the  Glasgow  Coma  Scale  plus  four  other 
variables.  Total  scores  can  range  from  1  16.  The  lower  the  score,  the  greater  the  severity  of  the  injury. 

A.  Glasgow  Coma  Scale 

The  Glasgow  coma  Scale  quantities  the  level  of  consciousness  by  measuring  three  aspect  of  neurologic 
function.  The  scale  was  developed  to  monitor  status  over  time. 

1.  Eye  opening 


a .  spontaneous  4 

b.  to  voice  3 

c.  to  pain  2 

d .  none  1 

2.  Verbal  response 


a.  oriented  5 

b.  confused  4 

c.  inappropriate  words  3 

d.  incomprehensible  sounds  2 

e.  none  or  intubated  1 

3.  Motor  response 


a.  obeys  command  6 

b.  localizes  pain  5 

c.  withdraws  from  pain  4 

d.  flexion  response  3 

e.  extension  response  2 

f .  none  1 


B,  Trauma  Score  Variables 
1.  Respiratory  Rate 


a.  10  24  per  min  4 

b.  24  35  per  min  3 

c.  >35  per  min  2 

d.  1-9  per  min  1 

e .  none  0 

2.  Respiratory  Expansion 
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a .  normal  1 

b.  refractive  0 

3 .  Systolic  blood  pressure 

a.  >90  4 

b.  70-89  3 

c.  50-79  2 

d.  0-49  1 

a .  none  0 

4.  Capillary  refill 

a .  normal  2 

b.  delayed  1 

c .  none  0 


C.  Total  Trauma  Score  (part  a  +  part  b) 
Conversion  for  Glasgow  coma  score 


Glasgow  Coma  Score 

Trauma  score  equivalent1 

11-13 

4 

8-12 

3 . 

Add  Glasgow  conversion  to  trauma  score  from  part  b  to  get  total  trauma  score. 


Probability  of  Survival  (Ps)  for  Trauma  Score  Values 


TS 

PS 

1-4 

<15% 

8-12 

50-80% 

5-7 

20-40% 

jl3-16 

>90% 
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APPENDIX  B :  Oxygen 

General; 


f  Appendix 


The  use  of  oxygen  is  indicated  by  your  assessment  and  by  the  specific  disorder  discovered. 

High  flow  rates  are  required  in  patients  with  evidence  of  respiratory  bums,  hypovolemia,  complicated 
deliveries,  and  /  or  signs  of  hypoxia  or  shock. 

The  use  of  high  flow  oxygen  in  patients  with  known  chronic  C02  retention,  a  small  subgroup  of  COPD 
patients,  may  cause  respiratory  arrest.  Note  that  high  flow  oxygen  should  not  be  withheld  from  these 
patients  when  assessment  indicates  hypoxia.  Carefully  monitor  respiratory  rate  and  effort  and  be 
prepared  to  assist  or  control  ventilation  as  required. 

If  Available  Pulse  Oximetry  readings  should  be  recorded  before  and  after  administration  of  oxygen. 


Humidified  Oxygen: 


The  administration  of  oxygen  is  necessary  and  therapeutic  in  transport  situations.  Adding  humidity  to  the 
flow  of  oxygen  should  not  delay  the  initial  use  of  oxygen  in  indicated  clinical  situations. 

Because  the  administration  of  oxygen  dries  the  mucus  membranes,  certain  situations  require  the  use  of 
humidified  oxygen. 

Such  situations  include  administration  of  oxygen  for  greater  than  four  hours  and  childhood  croup. 
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Succynl-choline 

1  mg/kg 

IV 

Fast 

None 

Thiamine 

100  mg 

IV 

Slow 

once  only 

Valium 

2  to  5  mg  i 

IV 

Slow 

BBai 

Verapamil 

IV 

Slow 

15  mg 

10  minutes 

Terbutaline 

imImH  B 

SQ 

Slow 

15  mg 

10  minutes 

Procainamide 

17  mg/kg  j 

IV _ J 

17  mg/kg 

once  only 

Atrovent 

Unit  dose  j 

Nebulized  I 

None 

20  minutes 

Drug 

Mix  Ratio 

Infuse 

Dopamine  j 

200  mg  in  250  cc 

2  to  20  ug/kg/min 

Lidocaine 

Procainamide 

lia'isgUawilB 
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APPENDIX  D  :  IV  Access-Saline  Locks-Drugs 

General  Standards 

Protection: 

Before  initiation  of  any  IV,  Employees  are  required  to  wear  protective  gloves,  mask,  and  goggles  for  the 
possibility  of  blood  splatter. 

Catheter  Size: 

The  catheter  size  implied  is  18  ga  if  possible.  Where  stated  largest  bore,  evaluate  the  success  of  a  14  to 
16  ga. 

Access: 

During  cardiac  arrest,  a  peripheral  vein,  antecubital  should  be  the  first  choice.  Drugs  require  1  2  minutes 
to  reach  the  central  circulation  when  given  by  a  peripheral  vein. 

IV  Medication: 

Intravenous  medications  should  be  administered  rapidly  by  bolus  injection  and  followed  by  a  20  ml 
bolus  of  IV  fluid,  this  can  be  achieved  by:  WIDE  OPEN  IV  and  squeeze  bag  for  a  20  cc,  and 
ELEVATION  OF  THE  EXTREMITY. 

Suggested  methods  of  elevation: 

1 .  Place  pillow  under  the  arm  used  for  IV  access 

2.  Use  Kerlex,  tape,  triangle  bandage  to  secure  arm  to  ceiling  rail,  or  IV  bag  hanger. 
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APPENDIX  E  :  Over  The  Counter  Medications 

The  providers  of  first  aid  recognize  that  certain  patrons  present  with  minor  complications  and  ask  for 
over  the  counter  medications.  The  following  medications  will  be  available  to  those  patrons  as  a  courtesy, 
and  as  part  of  our  service  as  providers  in  Medical  and/or  Rehab  sectors  at  extended  scenes  and  /or  stand 
by's. 

1.  Acetaminophen 

2.  Ibuprofen 

3.  Sudafed 

4.  Midol 

5.  Rolaids 

6.  Cepacol 

7.  Peptobismol 

8.  Imodium  AD 
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APPENDIX  F  :  Paramedic  Skills 

The  following  section  contain  skills  that  are  only  to  be  used  by  paramedics. 

1.  Nasotracheal  Intubation 

2.  Surgical  Cricothyroidotomy 

3.  Needle  Chest  Decompression 

4.  External  Jugular  Vein  Cannulation 

5.  Intraosseous  Needle  placement 

6.  Rapid  Sequence  Intubation 

7.  Esophageal  Obturator  Airway 

8.  Nasogastric  Tube 
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APPENDIX  G  :  Maximum  on  scene  attempts 

In  order  to  provide  the  best  possible  care  and  in  the  interest  of  the  patient,  the  following  limits  on 
intubation  and  IV  attempts  have  been  established: 

1.  IV  Access: 

a.  Non-eritical  and  urgent  patients:  There  shall  be  no  more  than  2  attempts  made  per  medic 
on  the  scene  and  no  more  than  3  total  attempts  made  on  scene.  If  an  IV  cannot  be 
established  within  the  limits  the  patient  is  to  be  transported  to  the  hospital  and  any  other 
attempts  shall  be  made  en  route  to  the  receiving  facility. 

b.  Critical  and  load  n  go  patients:  There  shall  be  no  more  than  2  attempts  made  on  scene, 
(unless  awaiting  for  extrication  or  helicopter  transport.)  If  an  IV  cannot  be  established 
within  this  limit  the  patient  is  to  be  transported  to  the  hospital  with  all  other  attempts 
done  in  route  to  the  receiving  facility. 

2.  Intraosseous  infusions:  There  shall  be  no  more  than  2 10  attempts  made  on  the  scene.  If  an  10 
cannot  be  established  within  this  limit  the  patient  is  to  be  transported  to  the  hospital  and  any 
other  attempts  shall  be  made  en  route  to  receiving  facility  And  WITH  ON  LINE  MEDICAL 
CONTROL  DIRECTION. 

3.  Intubation: 

a.  Critical  patients:  There  shall  be  no  more  than  2  attempts  made  per  medic  on  the  scene  and 
no  more  than  4  attempts  total  made  on  scene.  If  the  patient  cannot  be  intubated  within  the 
limits  the  patient  is  to  be  transported  to  the  hospital  and  any  other  attempts  at  intubation 
are  to  be  done  en  route  to  the  receiving  facility. 

b.  Load  n  Go  patients:  There  shall  be  no  more  than  2  intubation  attempts  made  on  the  scene. 
If  the  patient  cannot  be  intubated  within  this  limit  the  patient  is  to  be  transported  to  the 
hospital  and  or  any  other  attempts  shall  be  made  en  route  to  the  receiving  facility. 
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Do  Not  Resuscitate  Orders 

1.  Emergency  Calls  (  91 1)  :The  patient  or  family  member  in  calling  the  emergency  services 
triggers  a  presumption  that  resuseitative  measures  should  be  instituted.  The  vast  majority  of 
situations  would  require  immediate  institution  of  all  measures.  However ,  some  situations  arise  in 
which  a  particular  patients  desires  are  in  opposition  to  the  immediate  intervention  of  resuseitative 
techniques.  The  State  of  Texas  recognizes  the  right  of  a  patient  to  outline  their  own  desires  in  an 
Out  Of  Hospital  DO  NOT  RESUSCITATE  ORDER.  (See  chapter  674  of  the  Health  &  Safety 
Code)  Therefore  in  an  emergency  situation  immediate  resuscitation  will  be  performed  unless  the 
EMT  visualizes  either: 

a.  An  arm  Band  on  the  patient  signifying  the  Out  of  Hospital  Do  Not  Resuscitate  Order  has 
been  signed  or, 

b.  A  written  DNR  order  with  the  patient. 

2,  Transfer  Situations  (Non  911):Immediate  and  full  implementation  of  resuseitative  techniques  is 
the  standard  except  in  two  situations: 

a.  Hospice  patient:  Most  hospice  patients  have  made  arrangements  for  the  terminal  event 
prior  to  the  actual  event.  The  wishes  of  the  patient  should  be  honored  even  if  verbally 
communicated  from  a  hospice  representative. 

b.  Do  Not  Resuscitate  orders  either  from  a  facility  or  an  advanced  directive  should  be 
honored  if  presented  in  a  written  form.  Verbal  communication  of  such  orders  may  be 
respected  if  it  is  reasonable,  (e.g.  nurse  states  that  they  are  on  the  chart,  a  family  member 
states  they  exists  but  cannot  be  found  in  an  emergency.)  Evidence  of  foul  play  would  void 
any  such  reasonable  assumption. 
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APPENDIX  I :  Load  and  Go  Situations 

1,  Patients  who  shall  be  considered  for  immediate  emergency  transport  after  establishing  an  airway 
and  BLS  measures  have  been  initiated  are,  but  not  limited  to: 

a.  Significant  head  or  spinal  injuries  with  evidence  of  decreasing  neurological  status. 

b.  Blunt  or  penetrating  trauma  of  the  chest  and  /  or  abdomen  with  signs  of  decreasing  tissue 
perfusion. 

c.  Pediatric  arrest,  trauma  and  cardiac  ( less  than  2  years  old). 

d.  Obstetrical  patients  with  evidence  of  prolapsed  cord,  breech  delivery,  or  presentations. 

e.  Trauma  arrest. 


This  is  to  imply  that  if  a  patient  is  not  stabilized  on  scene,  then  initiate  ALS  protocols  in  route  to 
the  closest  appropriate  definitive  care  facility.  If  a  patient  is  considered  a  Load  and  Go  patient,  an 
immediate  transport  can  not  be  made  due  to  unusual  circumstances  (entrapment,  on  a  roof,  etc.) 
than  the  reasons  for  delay  shall  be  documented  on  either  the  Basic  Management  Form  or  an 
incident  report. 
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APPENDIX  J  :  Out  of  Radio  Contact  /  Beyond 

Medical  Control 

1.  Objective:  To  provide  guidelines  for  the  provision  of  necessary  emergency  medical  care  by 
Liberty  County  EMS  personnel  when  contact  with  a  physician  is  not  feasible  and  this  care  is  not 
covered  in  standing  orders. 

2.  Indications: 

a.  The  patient  needs  further  ALS  care  beyond  standing  orders. 

b.  The  treatment  requires  deviation  from  standing  orders.  Radio  or  phone  contact  with 
physician  is  not  feasible.  In  extreme  cases  where  the  time  required  to  establish  contact 
would  be  so  great  and  /  or  necessitate  leaving  the  patient,  that  it  would  be  detrimental  to 
the  patients  survival. 

3.  Procedure:EMS  treatment  should  be  consistent  with  current  established  treatment  guidelines 
and  when  the  course  of  treatment  is  not  specifically  addressed  by  protocol,  the  In  charge  medic's 
judgment  should  dictate  the  course  of  treatment  according  to  his  or  her  training  and  experience. 

4.  Precautions:All  treatment  rendered  by  Liberty  County  EMS  personnel  is  under  review  and 
liability  of  the  Medical  Director,  and  frill  and  complete  documentation  of  treatment  given  is 
required. 

Note: 

After  such  cases,  the  paramedic  shall  completely  document  in  narrative  form  all  reasons 
requiring  intervention  and  all  actions  taken  and  provide  to: 

1.  Clinical  Director 

2.  Medical  Director 

3.  Duty  Supervisor 
The  word  "CONSIDER" 

When  "consider"  is  used  in  these  protocols  it  is  an  option  of  the  paramedic  rather  than  an  order  to 
perform.  The  paramedics' judgment  should  dictate  this  course  of  treatment  according  to  his  or  her 
training  and  experience.  After  such  cases,  the  paramedic  in  charge  shall  completely  document  in 
narrative  form  to  Medical  Director. 
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APPENDIX  K  :  Physician  on  Scene 

1 .  Medics  shall  treat  all  physicians  on  scene  with  respect  and  shall  explain  any  questions  that  may 
arise. 

2.  A  physician  on  scene  who  is  caring  for  a  patient  prior  to  arrival  of  the  EMT  may  retain  medical 
responsibility  if  he  so  desires,  provided  that  he  will  accept  full  legal  and  medical  responsibilities 
and,  Iherefore,  accompany  the  patient  to  the  hospital  in  the  EMS  vehicle.  Only  then  will  orders 
given  by  physicians  on  scene  be  followed. 

3.  A  physician  on  scene  arriving  after  care  has  been  initiated  by  the  EMT  may  offer  his  services  to 
the  Medical  Control  Physician  who  shall  have  the  sole  authority  to  accept  or  deny  the  request. 

The  Medical  Control  Physician  ambulance  crew  /  physician  on  scene  shall  work  as  a  team  if  such 
permission  is  granted.  The  Medical  Control  Physician  may  refuse  to  honor  orders  he  feels 
medically  inappropriate  (according  to  established  protocols)  and  the  ambulance  crew  shall 
ultimately  be  responsible  to  the  Medical  Control  Physician.  Responsibility  for  transport  shall  be 
mutually  determined  by  the  physicians. 

4.  The  final  authority  for  medical  control  of  advanced  life  support  procedures  rests  with  the  Medical 
Control  Physician.  He  shall  have  personal  radio  communications  with  the  physician  on  scene. 

5.  In  the  event  an  on  scene  Physician  assumes  legitimate  medical  control,  but  then  refuses  to 
accompany  the  patient  to  the  hospital,  the  paramedics  will  revert  to  usual  protocols  and  medical 
control. 

6.  An  order  from  an  on-scene  physician  to  take  a  patient  to  a  hospital  which  is  not  the  closest,  most 
appropriate,  or  who  has  not  been  stabilized  according  to  protocol,  will  not  be  honored  unless  the 
physician  accompanies  the  patient. 
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Attributes  of  Jabber  as  Notifler 


Introduction 

The  Jabber  notification  system  has  the  following  key  features: 

•  XML  foundation 

•  distributed  network 

•  open  protocol  and  codebase 

•  modular,  extensible  architecture 

The  paragraphs  below  provide  a  high-level  overview  of  the  architecture  of  Jabber. 

Foundations 

Jabber  communications  are  made  possible  by  a  distributed  network  of  servers  that  use  a 
common  protocol,  to  which  specialized  clients  connect  to  receive  messages  as  well  as  to 
send  messages  to  users  of  the  same  server  or  any  other  Jabber  server  that  is  connected  to 
the  Internet. 

Jabber  delivers  messages  in  close  to  real  time  because  the  Jabber  server  (and,  by 
extension,  other  Jabber  users)  knows  when  a  particular  user  is  online.  This  knowledge  of 
availability  is  called  presence  and  is  the  key  enabler  of  instant  messaging.  Jabber 
combines  these  standard  IM  characteristics  with  two  additional  features  that  make  Jabber 
unique.  The  first  is  an  open  protocol  which  enables  interoperability  among  messaging 
systems.  The  second  is  a  strong  foundation  in  XML,  which  makes  structured,  intelligent 
messaging  possible  not  only  between  human  users  but  also  between  software 
applications. 

Client/Server 

Jabber  uses  client-server  architecture,  not  a  client-to-client  architecture  as  some  instant 
messaging  systems  do.  All  Jabber  messages  and  data  from  one  client  to  another  must  go 
through  the  server.  Any  client  is  free  to  negotiate  a  direct  connection  to  another  client, 
but  those  connections  are  for  application-specific  usage  only.  There  are  even  specific 
instances  where  this  is  encouraged,  such  as  file  transfers,  but  those  instances  are 
negotiated  first  within  the  context  of  a  client-server  framework. 

Distributed  Network 

Each  user  has  their  local  server  which  receives  information  for  them,  and  the  servers 
transfer  messages  and  presence  information  among  themselves.  There  can  exist  any 
number  of  Jabber  servers  which  accept  connections  from  clients  as  well  as  communicate 
to  other  Jabber  servers.  Each  server  functions  independently  of  the  others,  and  maintains 
its  own  user  list.  Any  Jabber  server  can  talk  to  any  other  Jabber  server  that  is  accessible 
via  the  Internet.  A  particular  user  is  associated  with  a  specific  server  (either  through 
registration  with  a  service  provider  or  administrative  setup  within  an  enterprise),  and 
Jabber  addresses  are  of  the  same  form  as  email  addresses,  e.g.,  stpeter@jabber.org. 
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Modular  Server 


The  Jabber  server  plays  two  primary  roles: 

•  Listening  for  client  connections  and  communicating  directly  with  client 
applications. 

•  Communicating  with  other  Jabber  servers. 

The  Jabber  open-source  server  is  designed  to  be  modular,  with  specific  code  packages 
that  handle  functionality  such  as  user  authentication,  data  storage  (offline  messages, 
rosters,  user  info),  and  the  like.  In  addition,  the  server  can  be  extended  with  additional 
services,  such  as  integrated  security,  allowing  special  connections  for  server-side 
components  or  alternative  clients,  and  gateways  to  other  messaging  systems. 

As  an  example  of  such  modularity,  the  exchange  of  messages  and  presence  information 
between  Jabber  and  any  given  non- Jabber  messaging  system  is  made  possible  by  means 
of  a  separate  "transport"  that  translate  Jabber  XML  into  the  foreign  protocol.  Such 
transports  are  not  part  of  the  core  server.  Instead,  they  are  server-side  programs  that  can 
be  added  rather  easily  to  the  core  server  to  provide  enhanced  functionality  to  the  end  user. 

Simple  Clients 

One  of  the  design  criteria  for  the  Jabber  system  was  that  it  must  be  capable  of  supporting 
simple  clients  (e.g.,  even  something  as  simple  as  a  telnet  connection).  Indeed,  the  Jabber 
architecture  imposes  very  few  restrictions  on  clients.  The  only  features  which  a  client 
must  support  are: 

•  Communicate  to  the  Jabber  server  via  TCP  sockets. 

•  Parse  and  interpret  well-formed  XML  packets. 

•  Understand  message  data  types. 

The  preference  in  Jabber  is  to  move  complexity  from  clients  to  the  server.  This  makes  it 
relatively  easy  to  write  clients  (as  witness  the  wide  variety  of  Jabber  clients  available 
today)  as  well  as  to  update  the  functionality  of  the  system  (i.e.,  without  forcing  users  to 
download  new  clients).  Jabber  clients  communicate  with  the  server  in  XML  through  TCP 
sockets  over  port  5222,  and  do  not  normally  communicate  with  each  directly.  In  practice, 
many  of  the  low-level  functions  of  the  client  (e.g.,  parsing  XML  and  understanding  basic 
Jabber  XML  such  as  <message/>,  <presence/>,  and  <iq/>)  are  handled  by  Jabber  client 
libraries,  enabling  client  developers  to  focus  on  the  user  interface. 

XML  Data  Format 

XML  is  an  integral  part  of  the  Jabber  architecture  because  it  is  of  utmost  importance  that 
the  architecture  be  fundamentally  extensible  and  able  to  express  almost  any  structured 
data.  (Specifically,  Jabber  utilizes  XML  Streams  for  client-server  and  server-server 
communication.  The  XML  Stream  is  always  initiated  by  the  client  to  the  server,  and  the 
lifetime  of  the  XML  Stream  is  directly  associated  with  the  lifetime  of  that  user's  online 
session.) 
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While  Jabber  is  strongly  committed  to  XML,  it  is  at  the  same  time  agnostic  with  regard  to 
the  delivery  medium:  there  are  no  inherent  restrictions  to  the  delivery  system,  and  no 
knowledge  within  the  architecture  of  the  delivery  system.  This  is  to  enable,  among  other 
things,  the  building  of  transports  that  provide  transparent  messaging  to  third-party 
services  .  However,  within  the  Jabber  system,  the  transport  speaks  XML,  as  does  every 
other  component  in  the  Jabber  system. 

High-Level  Server  Architecture 

The  Jabber  server  consists  of  multiple  components  that  handle  logically  separate 
functions  within  the  Jabber  system.  At  the  heart  of  the  server  lies  a  deliver  component 
whose  sole  function  is  to  direct  deserialized  XML  from  one  base  component  to  another. 
There  are  four  such  base  components:  accept,  connect,  exec,  and  load.  All  of  the  base 
components  deserialize  XML  input  for  delivery  to  other  base  components  and  reserialize 
XML  for  use  by  components  that  are  downstream  from  the  base  components.  Here  is  a 
high-level  view  of  the  architecture  just  described: 


On  server  start-up,  the  components  of  the  Jabber  server  register  callbacks  for  their 
responsibilities  with  the  main  Jabber  daemon  (as  defined  in  the  server  configuration  file), 
and  then  handle  packets  that  are  associated  with  those  responsibilities  (thereby  defining 
the  Delivery  Logic  for  all  packets).  The  core  Jabber  server  includes  components  that 
handle  the  following  common  tasks: 


•  session  management 

•  client-to-server  communication 

•  server-to-server  communication 

•  DNS  resolution 

•  user  authentication 

•  user  registration 
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•  database  lookups 

•  storing  messages  for  offline  users 

•  storing  and  retrieving  vCards 

•  filtering  messages  based  on  user  preferences 

•  group  chat  (many-to-many  communication) 

•  system  logging 

In  addition,  the  core  server  can  be  supplemented  with  "transports"  designed  to  handle 
protocols  that  are  foreign  to  Jabber's  open  XML  format  (see  Transports  for  details). 
These  transports  function  naturally  as  components  within  the  overall  server  architecture. 

Basic  Message  Flow 

A  good  entree  to  Jabber  architecture  is  to  look  at  the  flow  of  a  typical  message  through 
the  server.  (While  the  XML  'message'  element  is  only  one  of  the  three  main  elements  in 
Jabber's  open  XML  protocol,  it  is  the  one  most  central  to  the  purpose  of  Jabber:  to  route 
information  from  one  point  to  another  using  XML.) 

Here  is  a  diagram  of  that  flow: 


The  Jabber  server  (here  represented  by  the  term  'jabberd',  short  for  "Jabber  daemon") 
expects  to  receive  packets  of  type  'message'  in  the  context  of  a  user  session  on  that  host, 
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which  normally  will  take  place  through  a  dedicated  TCP  socket  on  port  5222  (or  port 
5223  if  SSL  is  enabled  and  in  use).  If  a  session  does  not  exist,  jabberd  will  initiate  the 
authentication  flow  as  described  below  under  Authentication.  If  a  session  does  exist,  the 
message  packet  will  be  sent  to  the  Jabber  session  manager  component  ('JSM'  for  short). 

Here  is  a  sample  of  what  the  XML  might  look  like: 

<message 

to-psaintandre@aim.jabber.org' 

type='chat’> 

<body>Hey,  the  AIM  transport  is  working  great  !</body> 

</message> 

Next,  the  JSM  checks  the  hostname  of  the  destination  server  against  the  list  of  names 
contained  in  the  Jabber  server's  internal  configuration  file.  Often  the  hostname  will  be 
defined;  for  example,  aim.jabber.org  is  defined  in  the  config  file  on  Jabber.com's  server 
to  point  to  the  AIM  Transport  for  that  host  (which  could  be  on  a  separate  machine).  If  the 
hostname  is  not  defined  in  the  config  file,  the  'dnsrv'  component  will  resolve  the 
hostname  to  an  IP  number  and  port.  Either  way,  the  message  packet  will  next  be  sent  on 
to  the  server-to-server  ('s2s')  component  for  the  host  in  question,  in  this  example 
jabber.org.  The  server-to-server  component  will  be  sent  directly  to  the  appropriate 
external  Jabber  server  (e.g.,  jabber.org)  or  to  a  transport  on  this  host.  In  this  example,  the 
message  packet  is  intended  for  delivery  to  an  address  on  aim.jabber.org,  so  the  packet 
will  be  sent  to  the  AIM  Transport  onjabber.org  for  subsequent  delivery  to  an  AOL 
Instant  Messenger  account  .In  either  case,  the  end  result  is  that  a  message  has  flowed 
from  a  Jabber  client  through  a  Jabber  server  to  either  another  Jabber  server  or  a  foreign 
IM  system. 

Authentication 

As  mentioned  already  under  Basic  Message  Flow,  messages  and  presence  notification 
are  sent  in  Jabber  within  the  context  of  a  user’s  session  on  a  host  machine  running  the 
Jabber  server.  In  the  terms  of  the  Jabber  protocol,  this  session  is  maintained  by  means  of 
two  XML  streams,  one  from  the  client  to  the  server  and  one  from  the  server  to  the  client. 
However,  in  order  for  die  server  to  create  a  session,  it  must  first  authenticate  the  user. 

The  authentication  flow  begins  when  the  client  connects  to  the  host  and  initiates  an  XML 
stream.  Immediately,  the  Jabber  server  checks  for  a  packet  of  type  *iq'  (short  for 
info/query)  and  subtype  'query'  in  the  'jabber:iq:auth'  namespace,  containing 
authenticating  information  for  the  user.  This  authenticating  information  must  consist  of  a 
username  and  resource  along  with  a  plaintext  password  (for  obvious  reasons  this  is 
discouraged),  a  password  scrambled  using  the  SHA1  algorithm  (this  authentication 
scheme,  a,k.a.  "digest  authentication",  is  the  default),  or  appropriate  data  for  zero- 
knowledge  authentication. 

Once  this  information  is  received,  the  XML  parser  passes  control  to  the  'deliver' 
component  of  the  Jabber  server,  which  will  begin  to  buffer  incoming  XML  if  the  client 
continues  to  send  XML  without  waiting  for  authentication.  The  host  (usually,  but  not 
always,  in  the  form  of  the  JSM)  will  then  pass  the  authentication  packet  to  the  'xdb' 
component  of  the  Jabber  server.  The  xdb  component  ('xdb'  stands  for  "Xml  Data  Base") 
will  send  the  packet  to  whichever  sub-component  has  registered  for  that  type  of 
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authentication  packet:  for  example,  plaintext  authentication  packets  might  be  checked 
against  XML  files  on  the  filesystem  using  the  'xbdfile'  sub-component,  whereas  digest 
authentication  packets  might  be  cheeked  against  LDAP  using  the  'xdb_ldap'  sub¬ 
component.  All  that  the  deliver  component  needs  to  do  is  hand  off  the  authentication 
packet  to  the  xdb  component,  which  will  send  it  to  the  appropriate  sub-component.  In 
addition,  to  improve  performance,  the  xdb_ldap  component  has  its  own  thread  pool, 
which  functions  in  a  way  similar  to  the  model  used  for  Threading  in  the  session 
manager. 

The  xdb  component  will  return  the  result  of  the  authentication  query  to  the  host  (again, 
usually  the  JSM).  If  the  authentication  failed,  the  server  will  return  error  code  401  to  the 
client  and  will  not  initiate  a  session.  If  the  authentication  succeeded,  the  JSM  will  start  a 
session  (and  free  up  the  XML  buffer  if  necessary).  From  that  point  forward,  all  presence, 
message,  and  iq  elements  will  be  passed  back  and  forth  in  the  context  of  a  user  session 
until  the  client  or  server  terminates  the  session  by  sending  a  closing  stream  tag 
(</stream>). 

Jabber  Session  Manager 

Here  is  the  activity  flow  of  the  Jabber  session  manager: 


As  mentioned,  the  Jabber  session  manager  component  (often  shortened  to  'JSM')  handles 
packets  of  type  message,  presence,  and  iq  to  and  from  a  Jabber  user  who  is  connected  to  a 
Jabber  host.  However,  the  JSM  will  also  handle  packets  intended  for  a  user  while  that 
user  is  offline.  For  example,  let  us  say  that  you  send  a  message  to  me  via  my  Jabber  ID 
(stpeter@jabber.org)  even  though  I  am  not  online.  The  JSM  will  handle  that  message 
appropriately,  most  likely  by  storing  it  until  I  am  again  online. 
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The  JSM  differentiates  between  online  and  offline  users  by  looking  for  the  'resource' 
element  in  the  XML  stream  (the  'resource'  is  the  device,  client,  or  location  with  or  from 
which  I  am  connected;  examples  of  these  might  be  'laptop',  'Gabber',  and  'home'). 
Normally,  a  user  is  offline  if  the  packet  does  not  contain  a  resource  element.  However, 
sometimes  the  resource  element  is  left  off  in  error,  so  the  JSM  checks  to  see  if  the  user 
really  is  offline  before  sending  a  packet  to  the  'offline'  component,  which  might  (for 
example)  store  a  message  or  retrieve  a  vCard. 

If  the  user  is  online,  the  message,  presence,  or  iq  packet  is  not  sent  to  the  offline 
component  but  instead  is  handled  by  the  JSM.  In  essence,  any  such  packet  can  have  only 
one  of  two  possible  states:  either  it  is  intended  to  be  delivered  to  the  user  or  it  is  being 
sent  from  the  user.  So  the  JSM  contains  two  listeners  that  listen  for  packets  "to"  or  "from" 
the  user  and  then  route  them  to  the  appropriate  module  within  the  Jabber  server.  Once  the 
appropriate  module  has  handled  the  packet,  the  packet  is  sent  back  to  the  listeners  for 
further  processing  by  more  modules  or,  if  all  processing  has  been  completed,  the  packet 
is  sent  out  to  or  from  the  user. 

It  may  be  helpful  to  look  at  an  example.  Let's  say  that  I  receive  a  message  from 
foobar@jabber.org.  I  am  online,  so  the  message  is  sent  to  the  JSM.  The  "to  listener"  hears 
about  a  packet  that  is  intended  for  me  and  sends  out  a  call  to  the  modules  that  have 
registered  with  the  JSM.  The  first  module  that  responds  is  mod_filter,  which  sorts 
through  incoming  messages  according  to  criteria  set  by  the  user.  In  this  case  (since  I 
never  seem  to  get  anything  critically  important  from  our  friend  foobar),  I  have  configured 
mod_filter  to  forward  all  messages  from  foobar@jabber.org  to  my  email  box  using  the 
hypothetical  but  planned  SMTP  Transport.  Let  us  say  that  mod_filter  reformats  the 
message  so  that  the  host  of  the  intended  recipient  is  now  smtp.jabber.org  instead  of 
jabber.org,  then  sends  the  packet  back  to  the  "to  listener".  Another  call  goes  out  to  the 
registered  modules,  but  none  reply  so  the  packet  is  sent  to  stpeter@smtp.jabber.org, 
which  duly  forward  it  to  my  email  inbox. 

The  important  thing  to  note  is  that  this  process  is  iterative,  so  that  multiple  modules  may 
handle  a  packet  before  it  is  finally  sent  to  or  from  a  user.  This  gives  the  JSM  a  great  deal 
of  flexibility  and  extensibility,  since  new  functionality  can  be  added  to  the  server  simply 
through  the  addition  of  a  new  module  (and  appropriate  changes  to  the  server 
configuration  file)  without  making  changes  to  the  JSM  itself  or  to  existing  modules. 

Threading 

The  Jabber  session  manager  uses  threading  to  improve  performance.  On  server  start-up,  a 
number  of  threads  are  assigned  to  the  thread  pool  (the  exact  number  is  determined  in  the 
configuration  file).  As  message  packets  are  fed  to  the  session  manager  through  the  base 
load  component  from  other  parts  of  the  system,  the  session  manager  dynamically  pulls 
unused  threads  from  the  thread  pool  and  associates  them  with  the  message  ports  for 
which  queued  packets  are  intended.  (A  "message  port"  is  a  data  structure  that  supports  a 
client  connection.)  If  no  threads  are  available  in  the  pool,  the  session  manager  may  (but  is 
not  required  to)  create  a  new  thread  and  associate  it  with  die  appropriate  message  port. 
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Delivery  Logie 

The  deliver  component  is  the  heart  of  the  server,  since  it  moves  data  from  one  base 
component  to  another.  The  logic  for  handling  data  at  this  level  is  shown  below: 
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Once  a  packet  is  delivered  to  one  of  the  base  components  (accept,  connect,  exec,  or  load), 
it  may  be  sent  to  a  sub-component  such  as  jpolld  or  xdbjdap  for  further  processing. 

An  example  of  a  precondition  might  be  an  xdb  result  (e.g.,  from  a  database  get)  that 
needs  to  be  handled.  An  example  of  a  process  condition  might  be  the  addition  of  a  route 
namespace  for  use  within  JSM.  And  an  example  of  changing  a  packet  for  delivery  might 
be  a  change  in  the  format  of  the  message,  e.g.  by  adding  a  from  address. 

Transports 

Although  the  construction  of  a  robust,  XML-based  messaging  system  is  the  core  goal  of 
the  Jabber  project,  an  important  sub-goal  is  the  achievement  of  interoperability  between 
messaging  systems.  Fundamentally,  the  Jabber  project  contributes  to  interoperability  by 
making  its  protocol  completely  open.  However,  it  also  contributes  by  enabling 
communication  between  Jabber's  open  XML  format  and  numerous  non-Jabber  formats 
through  the  use  of  what  in  the  Jabber  world  are  called  "transports". 

When  a  Jabber  user  sends  a  message  to  a  user  on  a  foreign  system,  the  delivery  of  that 
message  involves  the  work  of  a  transport  component.  The  user's  Jabber  client  sends  a 
message  to  the  Jabber  server  intended  for  a  user  on  a  foreign  IM  system,  denoted  by  a 
Jabber  ID  that  contains  the  name  of  the  foreign  system  (e.g., 

psaintandre@aim.jabber.org).  The  Jabber  server  then  routes  the  data  to  the  appropriate 
transport  application.  If  the  transport  is  local  (running  on  the  same  machine),  the  Jabber 
server  communicates  directly  to  it.  If  the  transport  is  running  remotely  (on  another 
machine),  then  the  local  server  passes  the  packet  to  the  remote  server,  which  then  passes 
it  to  the  appropriate  transport.  Once  the  transport  receives  the  XML  packet,  it 
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"transforms"  the  message  (or  instructions)  into  a  native  packet  which  is  readable  by  the 
other  IM  network,  and  passes  it  to  that  IM  network. 

Here  is  a  high-level  view  of  what  Jabber  transports  do: 


Functional  overview 
of  Jabber  transports 
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In  essence,  a  transport  implements  the  proxy  pattern.  Most  transports  contain  their  own 
small  session  manager,  which  translates  Jabber  XML  into  and  out  of  the  "foreign"  (non- 
Jabber)  protocol  for  presence,  messaging,  and  (in  some  cases)  info/query  requests.  In 
general,  when  a  user  logs  onto  Jabber,  a  thread  is  created  in  the  transport  to  handle  all 
communications  to  and  from  that  user. 

In  some  cases  the  translation  to  and  from  the  Jabber  protocol  is  fairly  straightforward,  for 
instance  when  the  foreign  protocol  is  well-documented  .In  other  cases,  the  translation  is 
made  more  difficult  by  the  closed  or  undocumented  nature  of  the  foreign  protocol . 

Subscriptions 

A  Jabber  entity  can  subscribe  to  the  presence  of  any  other  entity  (i.e.,  anything  with  a 
Jabber  ID).  A  subscription  is  essentially  an  agreement  by  the  "subscribee"  to  send 
presence  changes  to  the  subscriber.  This  information  is  stored  in  both  the  subscriber's 
roster  and  the  subscribers  roster.  When  I  authenticate  and  create  a  session  on  the  server, 
my  presence  information  is  stored  within  the  Jabber  Session  Manager.  Then  whenever  I 
change  my  presence  information,  the  <presence/>  packet  is  handled  by  the  server,  which 
does  a  lookup  in  my  roster  and  then  forwards  the  presence  packet  to  all  die  Jabber  entities 
that  have  subscribed  to  my  presence. 
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Subscriptions  fall  into  the  following  categories,  which  are  stored  in  the  rosters  of  the 
entities  involved: 

•  to  —  another  entity  sends  presence  information  to  you 

•  from  —  another  entity  receives  presence  information  from  you 

•  both  —  both  you  and  the  other  entity  send  and  receive  presence  information  from 
one  another 

•  none  --  neither  you  nor  the  other  entity  send  or  receive  presence  information  from 
the  other 

The  entity  sending  presence  does  not  have  to  be  another  Jabber  user,  but  instead  can  be 
an  outside  service  such  as  a  data  feed  or  a  non- Jabber  IM  system.  In  the  latter  case, 
subscriptions  to  users  on  the  non-Jabber  system  are  handled  through  a  transport,  and  the 
Jabber  user  registers  with  the  appropriate  transport  (e.g.,  icq.jabber.org)  in  order  for 
presence  to  be  passed  on  to  users  of  the  non-Jabber  system.  Once  the  Jabber  user  has 
successfully  registered,  the  transport  needs  to  know  whenever  the  owner  comes  online,  so 
it  sends  a  presence  subscription  request  to  the  submitter.  A  special  presence  subscription 
packet  is  sent  with  a  "from"  attribute  generated  by  the  transport,  with  embedded  data 
needed  to  login  to  the  native  protocol. 

The  Jabber  server  maintains  a  list  of  each  user's  subscriptions  (usually  in  a  spool 
directory  on  the  filesystem,  although  this  information  may  also  be  stored  in  a  database). 
This  list  is  called  a  roster  and  is  similar  to  what  in  other  IM  systems  is  called  a  "buddy 
list".  The  roster  in  Jabber  is  stored  on  the  server  and  thus  can  "follow"  the  user  from 
location  to  location  and  computer  to  computer.  The  Jabber  server  automatically  adjusts 
the  roster  to  reflect  subscription  types  when  people  authorize  or  refuse  subscription 
requests.  Rosters  can  also  contain  other  information  about  specific  users,  such  user 
nickneames  and  the  "groups"  to  which  that  user  belongs.  This  information  can  be  used  by 
the  client  to  display  the  roster  in  an  appropriate  interface,  e.g.,  a  treeview. 

Jabber  IDs 

Within  Jabber  there  are  many  different  entities  that  need  to  communicate  with  each  other. 
These  entities  can  represent  transports,  groupchat  rooms,  or  a  single  Jabber  user.  Jabber 
IDs  are  used  both  externally  and  internally  to  express  ownership  or  routing  information. 
Key  characteristics  of  Jabber  IDs  include: 

•  They  uniquely  identify  individual  objects  or  entities  for  communicating  instant 
messages  and  presence  information. 

•  They  are  easy  for  users  to  remember  and  express  in  the  real  world. 

•  They  are  flexible  enough  to  enable  the  inclusion  of  other  IM  and  presence 
schemes. 

Each  Jabber  ID  (or  "JID")  contains  a  set  of  ordered  elements.  The  JIDs  are  formed  of  a 
domain,  node,  and  resource  in  the  following  format: 

[node@]domain[/resouree] 

The  Jabber  ID  elements  are  defined  as  follows: 
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•  The  Domain  Name  is  the  primary  identifier.  It  represents  the  Jabber  server  to 
which  the  entity  connects.  Every  usable  Jabber  domain  should  resolve  to  a  Fully 
Qualified  Domain  Name. 

•  The  Node  is  the  secondary  identifier.  It  represents  the  "user".  All  Nodes  live 
within  a  specific  Domain.  However,  the  Node  is  optional,  and  a  specific  Domain 
(e.g.,  conference.jabber.org)  is  a  valid  Jabber  ID. 

•  The  Resource  is  an  optional  third  identifier.  All  Resources  belong  to  a  Node. 
Within  Jabber  the  Resource  is  used  to  identify  specific  objects  that  belong  to  a 
user,  such  as  devices  or  locations.  Resources  enable  a  single  user  to  maintain 
several  simultaneous  connections  to  the  same  Jabber  Server;  examples  might  be 
juliet@capulet.com/balcony  vs.  juliet@capulet.com/chamber. 

A  Jabber  user  always  connects  to  a  server  by  means  of  a  particular  resource  and  therefore 
has  an  address  of  the  form  node@domain/resource  while  connected  (e.g., 
juliet@capulet,com/balcony).  However,  since  the  resource  is  session-specific,  the  user's 
address  can  be  communicated  as  node@domain  (e.g.,  juliet@capulet.com),  which  is 
familiar  to  people  since  it  is  of  the  same  form  as  most  email  addresses. 

Note  that  in  some  circumstances  messages  may  be  sent  directly  to  a  specific  resource,  but 
in  general,  a  message  destined  forjuliet@capulet.com  is  routed  based  on  some  rules  in 
the  Jabber  server,  since  each  connection  instance  can  have  its  own  priority  setting.  Thus, 
if  a  message  is  just  sent  tojuliet@capulet.com  (i.e.  without  specifying  a  resource),  the 
message  is  routed  to  the  resource  which  has  the  highest  priority,  e.g. 
juliet@capulet,com/balcony. 
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ABSTRACT 

The  development  of  a  civilian  corps  of  first 
responding  emergency  medical  technicians  (EMT) 
and  paramedics  during  the  past  several  decades, 
which  was  in  many  ways  an  extension  of  that  which 
has  long  existed  among  military  eorpsmen,  has  had  a 
very  positive  impact  on  the  survival  of  all  types  of 
injuries  and  acute  illnesses.  The  reality  is,  however, 
that  the  interpretation  of  a  victim’s  clinical  problems 
and  therapies  instituted  are  at  this  time  dependent 
upon  the  individual  caregiver’s  training,  judgment, 
and  experience.  It  is  hypothesized  that  having  a 
virtual  physician  present  at  the  scene  through  the 
technology  of  modem  telecommunications  will  have 
a  favorable  impact  on  patient  outcome  in  many 
instances.  Through  the  application  of  telecommunica¬ 
tion  technologies,  The  University  of  Texas  Health 
Science  Center  at  Houston  (UTH3CH)  proposes  to 
virtually  bring  the  physician  to  the  scene  of  the 
incident,  thereby  allowing  on-line  physician 
evaluation  and  intervention. 


Light  areas  =  mortality  at  or  below  state  average 
Dark  areas  =  mortality  above  the  state  average 

Figure  1*  State  of  Texas  Unintended  Injury,  Motor 
Vehicle  Injury,  and  Work-Related  Injury  Deaths 
Per  100,000  People1 


INTRODUCTION 

That  life  threatening  injuries  and  acute  illnesses  occur 
on  the  battlefield,  on  highways  and  urban  settings  is  a 
harsh  reality.  It  is  also  a  fact  that  early,  accurate  di¬ 
agnoses  and  institution  of  appropriate  therapy  im¬ 
prove  survival  in  many  instances.  During  recent  dec¬ 
ades,  significant  progress  has  been  made  in  reducing 
the  interval  between  the  onset  of  the  problem  and  the 
institution  of  treatment  as  a  result  of  the  development 
of  skilled  medics  and  paramedics  and  improved 
equipment  modes  of  rapid  transportation.  However, 
progress  is  often  lagging  in  rural  areas  and  other  set¬ 
tings  where  locating  the  patient  and  getting  first  re¬ 
sponders  to  the  scene  is  hampered  by  either  distance 
or  terrain,  and  the  sparseness  of  the  facilities  in  these 
areas  often  hampers  die  delivery  of  optimal  care  to 
these  patients  (Figure  1). 

This  study  was  done  under  the  Advanced 
Research  Projects  Agency  (ARP A)  funded  project 
titled  “Advanced  Fire  Protection  Technologies,” 
June  23,  1995,  where  UTHSCH  tested  a  prototype 
“Emergency  Information  Resource  and  Response 
Management  System.”2  The  project’s  goal  was  to 
improve  the  diagnosis  and  treatment  of  critically  ill 
or  injured  people  in  the  field  by  expediting  their 
access  to  medical  experts  at  the  Texas  Medical 
Center  through  the  utilization  of  various  modem 
technologies. 

The  hypothesis  that  drives  ail  work  on  the  pro¬ 
ject  is  that  pre-hospital  video,  audio,  and  physiologi¬ 
cal  data  transmitted  between  the  remote  site  of  initial 
patient  intervention  and  a  supervising  physician  will 
favorably  impact  patient  outcome. 

BACKGROUND 

The  objective  of  this  project  was  to  demonstrate  the 
potential  for  improving  the  overall  effectiveness  of 
fire  rescue  and  associated  emergency  medical  ser¬ 
vices  (EMS)  through  the  use  of  state-of-the-art  tech¬ 
nologies.2  In  particular,  a  Cypress-Fairbanks  Volun¬ 
teer  Fire  Department  (Cy-Fair  EMS)  civilian  ambu¬ 
lance  in  the  suburban  Houston,  Texas  area  was  outfit¬ 
ted  with  advanced  technologies,  including  display 
and  data  processing  systems,  mobile  communication 
systems,  Marquette  12-lead  ECG,3  a  Protocol  Propaq 
1054  vital  signs  monitor,  and  a  commercial  GPS 
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GPS  Satellite 


Medical  Control 
{Physician’s  Station) 


Figure  2,  System  Overview 

navigation  system,5  Transmission  of  data  from  the 
ambulance  to  the  hospital  was  done  through  4  analog 
cellular  telephone  modems,  while  the  12-lead  ECG 
was  sent  over  a  separate  cellular  telephone  line. 
Figure  2  shows  system  overview. 

The  receiving  hospital.  Memorial  Hermann 
Hospital  (MHH)  in  Houston,  Texas,  had  a  computer 
with  similar  display  and  data  processing  systems. 
Pre-hospital  vita!  signs  and  video  signals  were 
transmitted  by  modem  to  a  private  hospital  telephone 
bank  of  4  telephone  lines.  The  receiving  station  for 
the  Marquette  12-lead  ECG  had  an  additional 
telephone  line. 

The  evaluation  and  merit  analysis  consisted  of 
realistic  scenarios  that  were  prepared  by  UTHSCH 
and  MHH  Life  Flight,2  Baseline  historical  data  from 
the  Houston  Fire  Department  for  previous  EMS  runs 
were  used  to  determine  the  baseline  effectiveness  for 
comparison  of  the  new  technology  in  this  project  to 
then  current  fire  and  EMS  standard  of  care.  During 
the  period  of  study,  January  1995  through  July  1995, 
45  total  ambulance  runs  of  different  types  were  col¬ 
lected,  In  14  cases  of  these  the  use  of  video  and  pa¬ 
tient  telemetry  had  the  potential  for  a  positive  impact 
(2  cardio-vaseular,  1  neurologic-stroke,  7  motor  ve¬ 
hicle  accident,  3  pediatric,  and  1  obstetric). 

CASE  STUDY 

At  approximately  22:00  on  a  Friday  night,  an 
ambulance  staffed  by  a  emergency  medical 
technician  paramedic  (EMT-P),  EMT  basic,  EMT 
student  and  1  of  the  authors  (RDT)  observing, 
responded  to  a  41 -year-old  male  with  history  of  high 
cholesterol,  hypertension,  myocardial  infarction  2 


years  previously,  and  lower  GI  surgery  to  remove 
polyps. 

Upon  arrival  the  patient  was  found  in  bed 
complaining  of  chest  pain  radiating  down  his  left  arm 
with  weakness  and  slight  difficulty  breathing.  Upon 
initial  physical  examination,  skin  color  was  good 
warm  and  dry.  The  Glasgow  coma  score  (GCS)  was 
15,  His  pupils  were  equal  and  reactive  and  he  had 
clear  bilateral  breath  sounds.  Abdomen  was  soft  and 
non-tender  although  patient  is  obese.  Extremities 
were  unremarkable  with  positive  distal  pulses,  no 
noted  edema,  positive  capillary  refill  response.  Weak 
grip  was  noted  in  upper  extremities. 

At  22:04  vitals  were  obtained  (bp:  150/104,  hr 
84,  rr  20)  and  placed  on  12L/min,  on  non-rebreather 
mask.  Cardiac  monitoring  was  started,  showing  signs 
of  sinus  rhythm  with  depressed  ST  segment  at  hr  80 
bpm.  At  22:15  vitals  were  obtained  (bp:  206/128,  hr 
100,  rr  16)  and  was  transferred  to  the  ambulance  and 
a  12-lead  ECG  was  applied  and  showed  sinus  rhythm 
with  nonspecific  ST  segment  abnormality,  and 
abnormal  ECG,  At  22:18  (bp:  206/128,  hr  74) 
intravenous  access  was  established  of  9%  saline 
solution. 

At  22:21  (bp:  206/131,  hr  74,  rr  20)  RDT 
initiated  digital  communication  and  transmitted 
patient  data  to  medical  control  at  MHH.  Figure  3 
shows  a  video/vital  signs  screen  from  this  run,  EMT- 
P  called  Medcon  by  cellular  telephone  and  gave 
patient  information  to  Carolyn  Galloway,  MD, 
Patient  vitals  (bp,  spo2,  and  ECG)  and  video  were 
transferred.  Dr.  Galloway  corrected  a  problem  with 
lead  positioning  of  the  ECG  after  viewing  the  video 
and  the  received  12-lead  ECG.  Nitro  sublingual  0.4 
was  ordered  at  22:21  and  patient  reported  no  relief. 
Dr,  Galloway  made  the  decision  to  transport  by  MHH 
Life  Flight  based  on  local  ER  and  cardiac 
catheterization  lab  availability.  Ambulance  instructed 
to  drive  to  a  prearranged  landing  zone  and  wait  for 
Life  Flight, 

At  22:24  (bp:  191/131,  hr  76,  rr  16,  99%  spo2) 
Dr,  Galloway  ordered  10  mg  Procardia™ 6  and 
instructed  the  patient  to  bite  and  swallow,  but  patient 
declined.  Chest  pain  continued  at  a  rate  of  8  on  a  1- 
10  scale.  At  22:27  (bp:  191/128,  hr  83,  99%  spo2) 
patient  continued  to  experience  chest  pain  without 
nausea,  vomiting,  dizziness,  or  lightheadedness.  At 
22:30  patient  continued  to  be  hypertensive,  and 
Dr.  Galloway  ordered  magnesium  sulfate  4mg  IV 
push.  At  22:31  (bp  208/124,  hr  91,  rr  20, 100%  spo2) 
second  12  lead  ECG  was  sent  to  medical  control,  and 
remained  unchanged.  Dr,  Galloway  ordered  one  half 
adult  aspirin  (325mg)  by  mouth,  but  patient  refused 
water  and  swallowed  it.  At  22:36  (bp:  184/130,  hr  79, 
rr  20,  100%  spo2)  continued  to  monitor  patient  and 
he  began  to  gasp  for  air.  He  still  denied  any  chest 
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Figure  3.  Video  and  Vitals  from  Case  Study 


pain  relief.  At  22:40  vitals  were  (bp:  194/124,  hr  81, 
rr  20, 100%  spo2) 

Dr.  Galloway  advised  to  continue  to  monitor 
patient  and  advised  that  Life  Flight  could  see  the 
landing  zone.  Patient  was  transferred  to  Life  Flight 
and  proceeded  by  air  transport.  Patient  was 
monitored  and  assessed  by  Life  Flight  personnel  and 
upon  arrival  at  MHH  patient  received  definitive  care 
of  a  cardiac  catheterization  within  4  hours  of  initial 
ambulance  arrival.  The  patient  returned  to  the 
community  for  follow-up  by  his  local  cardiologist 
and  primary  care  physician  within  36  hours  of 
admission. 

This  case  was  of  particular  note  because  of  the 
use  of  video  imagery  to  correctly  place  the  12-lead 
ECG  in  the  field.  Since  the  patient  was  being  con¬ 
tinually  monitored  and  telemetry  was  sent  automati¬ 
cally  to  medical  control.  Dr.  Galloway  could  imme¬ 
diately  see  the  responses  to  therapy  and  continue  ad¬ 
vanced  pre-hospital  care.  The  presence  of  the  12-lead 
ECG  and  the  expert  interpretation  via  the  telemedi¬ 
cine  link  was  effective  for  the  patient  diagnosis. 
Without  the  advanced  technologies  onboard  he  could 
have  been  transported  to  the  local  ER,  which  could 
have  dramatically  delayed  cardiac  catheterization. 


CONCLUSIONS 

While  the  sample  of  cases  may  not  be  wholly 
representative  of  the  mix  of  cases  seen  by  the  Cy-Fair 
EMS,  they  did  illustrate  the  potential  for  benefit  with 
advanced  equipment  and  telecommunication  tech¬ 
nologies.  The  14  cases  showing  positive  potential  for 
video  impact,  including  the  aforementioned  case 
study,  showed  promise  in  this  feasibility  study.  The 
success  and  positive  impact  of  remote  telemetry  and 
patient  video  qualitatively  proved  the  hypothesis  and 
encouraged  further  research  and  development  in  this 
area. 

CURRENT  WORK 

Based  on  the  early  lessons  learned  in  this  ARPA 
project,  the  Disaster  Relief  and  Emergency  Medical 
Services  (DREAMS™)  project  started.  DREAMS™ 
is  a  U.S.  Army-funded  consortium  of  scientists, 
medical  professionals,  and  engineers  from  UTHSCH 
and  the  Texas  A&M  University  System.  The  goal  of 
the  DREAMS™  Digital  EMS  project  is  to  improve 
the  diagnosis  and  treatment  of  critically  ill  or  injured 
soldiers  or  civilians  in  the  field  by  expediting  their 
access  to  medical  experts  at  trauma  centers  or  field 
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hospitals  through  the  utilization  of  various  modem 
technologies.  Digital  EMS  is  testing  the  new  systems 
developed  in  this  program  in  varied  rural,  remote, 
and  urban  settings  in  Texas.  We  hope  to  qualify  and 
overcome  not  only  the  technology  issues  while  com¬ 
municating  with  mobile  distant  emergency  vehicles, 
but  also  to  develop  procedures  for  telementoring  of 
remote  medics  and  other  medical  personnel  through 
the  transportation  and  transfer  of  critically  injured 
people. 

The  Digital  EMS  project  is  just  one  part  of  the 
DREAMS™  project  and  is  designed  to  allow  trauma 
and  other  medical  specialists  to  treat  patients  more 
quickly  by  providing  a  “virtual”  presence  of  a  physi¬ 
cian  on  the  battlefield  or  at  the  emergency  scene. 
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ABSTRACT 

While  other  works  may  have  discussed  what  makes  a 
good  clinical  algorithm ,  and  even  discussed  the  im¬ 
portance  of  good  algorithms ,  there  has  not  been  a 
discussion  of  the  classification  of  algorithms  other 
than  to  say  whether  or  not  an  algorithm  meets  the 
criteria  to  be  called  “good. "  This  work  presents  a 
classification  scheme  that  separates  algorithms  into 
five  classes  based  on  the  level  of  detail  present  in  the 
algorithm , 

INTRODUCTION 

Increasingly,  clinical  care  algorithms  are  being 
computerized  to  serve  many  different  roles:  teaching 
tools,  quality  improvement  /  monitoring  tools,  re¬ 
search  tools,  and  as  part  of  routine  clinical  care.  As 
computers  have  no  native  intelligence,  it  is  necessary 
to  make  die  algorithms  as  detailed  as  possible  to  both 
streamline  the  implementation  process  and  try  to  en¬ 
sure  that  the  computerized  algorithm  represents  what 
we  want  to  do,  not  just  want  we  told  the  computer  to 
do. 

While  other  works  may  have  discussed  what 
makes  a  good  clinical  algorithm,  and  even  discussed 
the  importance  of  good  algorithms,  there  has  not  been 
a  discussion  of  the  classification  of  algorithms  other 
than  to  say  whether  or  not  an  algorithm  meets  the 
criteria  to  be  called  “good.”* *3 

CLASSIFICATIONS 

Class  0 

Class  0  algorithms  are  often  encoded  only  in  textual 
form.  These  algorithms  are  usually  foil  of  the  vaga¬ 
ries  necessary  to  get  a  document  through  the  consen¬ 
sus  process  and  foil  to  adequately  describe  the  deci¬ 
sions  and  actions  that  are  required  to  care  for  the  pa¬ 
tient.  The  actual  algorithm  is  often  unstructured  or 
poorly  structured  and  may  follow  no  sequential  order 
based  on  either  time  or  logical  progression  of  a  pa¬ 
thology  or  treatment  course.  Important  entry  or  ex¬ 
clusion  criteria  and  conditional  values  often  appear 
at  the  end  of  the  algorithm  or  in  footnotes,  if  at  all. 

Class  1 

Class  1  algorithms  improve  upon  Class  0  algorithms 
by  specifying  all  of  the  entry  and  exclusion  criteria  at 
the  beginning  of  the  algorithm  description.  The  algo¬ 
rithms  steps  are  coarsely  structured  and  are  arranged 
in  a  temporal  or  logical  progression.  These  algo¬ 
rithms  are  usually  still  represented  in  textual  form, 
but  may  also  be  represented  in  other  forms. 


Class  2 

Class  2  algorithms  improve  upon  Class  1  algorithms 
by  explicitly  defining  all  thresholds  and  decisions 
within  the  algorithms.  Some  action  steps  are  also 
defined. 

Class  3 

Class  3  algorithms  are  distinguished  from  Class  2 
algorithms  by  the  representation  format  and  the  pres¬ 
ence  of  definitions  for  all  steps.  Class  3  algorithms 
are  represented  using  some  structured  formalism, 
such  as  flow  diagrams  or  formal,  structured  text 
(pseudo-code). 

Class  4 

Class  4  algorithms  include  all  of  the  details  necessary 
for  a  non-expert  or  computer  to  negotiate  the  algo¬ 
rithm  in  a  reliable  and  repeatable  manner.  All  logical 
and  clinical  concepts  are  explicitly  spelled  out  and 
are  described  in  terms  of  patient-specific  values. 
These  algorithms  are  most  often  disseminated  as  ei¬ 
ther  flow  diagrams  or  encoded  using  a  knowledge 
base  formalism. 

As  it  is  possible  for  a  given  clinical  algorithm  to  ful¬ 
fill  all  of  the  requirements  for  a  given  classification 
and  part  of  the  requirements  for  a  higher  classifica¬ 
tion,  it  may  be  necessary  to  classify  the  algorithm  as 
a  intermediate  value.  This  is  done  by  separating  the 
two  levels  with  a  forward  slash  (/),  such  as,  “Class  3  f 
4”.  This  notation,  while  less  precise  than  a  decimal 
or  true  fractional  notation,  has  the  advantage  of  being 
simple  and  efficient. 

References 

1.  Clemmer  TP,  Spuhler  VJ.  Developing  and  gain¬ 
ing  acceptance  for  patient  care  protocols.  New 
Horiz  1998;  6:12-9. 

2.  East  TD,  Moms  AH,  Wallace  CJ,  et  al.  A  strat¬ 
egy  for  development  of  computerized  critical 
care  decision  support  systems.  Int  J  Clin  Monit 
Comput  1991;  8:263-9, 

3.  Sailors  RM.  Moving  Arden  Syntax  Outside  of 
the  (Alert)  Box:  A  Paradigm  for  Supporting 
Multi-Step  Clinical  Protocols.  Journal  of  the 
American  Medical  Informatics  Association 
1998;  5:1071. 

Acknowledgements: 

Support  for  this  work  was  provided  by  NIGMS  P50 
GM38529  and  DAMD 17-98-2-8002. 


220 


APPENDIX  10 


ArdenML:  The  Arden  Syntax  Markup  Language 
( or  Arden  Syntax:  It’s  Not  Just  Text  Any  More! ) 

R.  Matthew  Sailors,  PhD 

University  of  Texas-Houston  Health  Science  Center 
Medical  School,  Department  of  Surgery,  Houston,  TX  77030 


ABSTRACT 

It  is  no  longer  necessary  to  think  of  Arden  Syntax 
as  simply  a  text-based  knowledge  base  format  The 
development  of  ArdenML  (Arden  Syntax  Markup 
Language ),  an  XML- based  markup  language  allows 
structured  access  to  most  of  the  maintenance  and 
library  categories  without  the  need  to  write  or  buy  a 
compiler  may  lead  to  the  development  of  simple 
commercial  and  freeware  tools  for  processing  Arden 
Syntax  Medical  Logic  Modules  (MLMs) 

LEVELS  OF  ENCODING 

Borrowing  the  concept  of  levels  of  detail  from 
other  groups  within  HL7  (Health  Level  Seven,  Inc),  a 
numeric  coding  scheme  for  identifying  die  level  of 
detail  was  developed  and  presented  to  the  Arden  Syn¬ 
tax  Special  Interest  Group  (Arden  SIG),  The  levels 
are  numbered  from  0  to  4  in  increasing  level  of  detail. 

Level  0 

Level  0  encoding  simply  wraps  existing  Arden 
Syntax1  MLMs  in  their  entirety  inside  a  large 
CDATA  (character  data)  construct.  The  CDATA 
type  is  used  to  allow  for  the  commonly  used  greater 
than  and  less  than  signs  (“>”,  “<”)  that  are  used  as 
tag  delimiters  in  XML-derived  markups. 

Level  1 

Level  1  ArdenML  encodes  the  Arden  Syntax 
hierarchy  of  categories  and  slots.  Each  category  be¬ 
comes  a  collection  of  substructures  (the  slots)  and 
each  slot  is  represented  as  a  separate  CDATA  field. 
It  is  important  to  note  that  at  ArdenML  Level  1  and 
higher,  the  normal  category  and  slot  identifiers  and 
all  terminators  /  “;;”)  have  been  replaced  by  tags. 

Level  2 

Level  2  of  ArdenML  adds  another  layer  of  struc¬ 
ture  to  model.  The  structures  added  to  the  citation 
and  links  slots  in  Arden  Syntax  Version  2  and  addi¬ 
tion  structuring  of  the  author,  specialist,  and  keyword 
slots  that  have  been  proposed  for  Arden  Syntax  Ver¬ 
sion  3  first  appear  in  ArdenML  Level  2  encoding. 
Additional  elements  representing  many  of  the  coded 
values  within  Arden  Syntax  are  also  present. 

Level  3 

Level  3  encoding  introduces  the  structuring  of 
whole  statements  and  control  structures.  ArdenML 
encodes  the  blocks  of  statements  inside  control  struc¬ 
tures  as  nested  constructs  with  additional  nesting  of 


the  statement  blocks  that  appear  in  ifthen-else-elseif 
conditional  statements  or  within  loops.  This  repre¬ 
sentation  simplifies  the  processing  of  the  encoded 
MLM  and  is  in  keeping  with  the  model  of  adding  of 
additional  structure  to  the  MLM  as  the  level  of  en¬ 
coding  increased.  Tags  to  encode  comments,  identi¬ 
fiers,  referenced  MLMs,  and  tokens  used  to  structure 
data  have  also  been  added  in  ArdenML  Level  3, 

Level  4 

Level  4  encoding  structures  Arden  Syntax  down 
to  the  level  of  operators  and  operands.  A  DTD  for 
ArdenML  Level  4  has  not  been  developed  at  this 
time,  as  this  requires  the  reimplementation  of  the 
entire  Arden  Syntax  BNF  (Backus-Naur  Form)  in 
XML-based  constructs.  This  was  deemed  to  be  un¬ 
necessary  for  this  preliminary  work  product. 

CONCLUSIONS 

At  this  time  it  is  not  clear  if  encoding  Arden 
Syntax  beyond  Level  2  has  any  real  value  other  than 
as  an  academic  exercise.  However,  as  XML  transla¬ 
tion  tools  begin  to  multiply,  ArdenML  Levels  3  and  4 
may  become  practical.  ArdenML  Levels  2  and  3  also 
show  promise  as  intermediary  forms  to  be  used  dur¬ 
ing  development  and  maintenance  of  MLMs  using 
componentized  development  tools. 

FUTURE  DIRECTIONS 
An  exploration  of  the  use  of  XST  (XML 
Stylesheet  Translation)  to  translating  MLMs  into 
other  program  constructs  mming/knowledge  repre¬ 
sentations  without  having  to  build  a  traditional  com¬ 
piler  is  planned. 
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APPENDIX  11 


Provide  the  following  information  for  the  key  personnel  listed  on  the  budget  page. 


NAME 

James  Henry  Duke.  MD 


POSITION  TITLE 
Professor  of  Surgery 


EDUCATION/TRAINING  (Begin  with  baccalaureate  or  other  initial  professional  education,  such  as 
nursing,  and  include  post-doctoral  training). 


INSTITUTION  AND  LOCATION 

DEGREE  (IF 
APPLICABLE) 

YEAR(S) 

FIELD  OF  STUDY 

UT  Southwestern  Medical  School-Dallas 

MD 

1960 

Medicine 

Southwestern  Baptist  Theological  Seminary-Ft  Worth 

BD 

1955 

Divinity 

AScM  College  of  Texas 

BS 

1950 

Columbia  University,  New  York 

Postdoctoral 

1967-69 

Chem,  Eng,  Biochemistry 

Columbia  University,  New  York 

Postdoctoral 

1967-69 

NIH  General  Medical  Sciences 

Parkland  Memorial  Hospital,  Dallas  TX 

Residency 

1961-65 

General  Surgery 

Parkland  Memorial  Hospital,  Dallas  TX 

Internship 

1960-61 

Medicine 

RESEARCH  AND  PROFESSIONAL  EXPERIENCE:  Concluding  with  present  position,  list  in  chronological  order,  previous 
employment,  experience,  and  honors.  Include  present  membership  on  any  Federal  Government  public  advisory  committee. 
List  in  chronological  order,  the  titles,  all  authors,  and  complete  references  to  all  publications  during  the  past  3  years  and  to 
representative  earlier  publication  pertinent  to  this  application.  If  the  list  of  publications  in  the  last  3  years  exceeds  2  pages, 
select  the  most  pertinent  publications.  PAGE  LIMITATIONS  APPLY.  DO  NOT  EXCEED  3  PAGES  FOR  THE  ENTIRE 
BIOGRAPHICAL  SKETCH  PER  INVESTIGATOR. 

ACADEMIC  APPOINTMENTS 

1965- 66  Instructor  in  Surgery,  The  University  of  Texas  Southwestern  Medical  School,  Dallas  TX 

1966- 69  Asst  Prof  of  Surgery,  The  University  of  Texas  Southwestern  Medical  School,  Dallas  TX 

1 969- 72  Asst  Prof  of  Surgery,  College  of  Physicians  and  Surgeons,  Columbia  University,  New  York  NY 

1 970- 72  Visiting  Professor  of  Surgery,  Nangarhar  University,  Faculty  of  Medicine,  Jalalabad,  Afghanistan 

1971- 72  Chairman,  Dept  of  Surgery,  Nangarhar  University,  Faculty  of  Medicine,  Jalalabad,  Afghanistan 

1972- 73  Associate  Professor  of  Surgety,  The  University  of  Texas  Health  Science  Center  at  Houston  Medical 

School,  Houston  TX 

1977- 87  Special  Assistant  to  the  President,  The  University  of  Texas  Health  Science  Center  at  Houston 

1978- 86  Professor  and  Medical  Director,  The  University  of  Texas  Health  Science  Center  at  Houston  School  of 

Allied  Health  Sciences,  Program  in  Emergency  Medical  Services 
1978-82  Vice  Chairman  for  Clinical  Affairs,  The  University  of  Texas  Health  Science  Center  at  Houston 
Medical  School 

1991-95  Vice  Chairman,  Department  of  Surgery,  The  University  of  Texas  Health  Science  Center  at  Houston 
Medical  School 

1 973-  Professor  of  Surgery,  The  University  of  Texas  Health  Science  Center  at  Houston  Medical  School 
1986-  Visiting  Member,  Graduate  Faculty  Texas  A&M  University  College  of  Veterinary  Medicine,  College 

Station  TX 

1994-  Professor  of  Emergency  Medicine,  The  University  of  Texas  Health  Science  Center  at  Houston 
Medical  School 

1995-  Vice  Chairman  of  Development,  Department  of  Surgery,  The  University  of  Texas  Health  Science 
Center  at  Houston  Medical  School 

CERTIFICATIONS 

1993  Advanced  Trauma  Life  Support  Provider,  1993 
1996  American  Board  of  Surgery,  1 966 

1970  License  Practice  Medicine  in  Texas,  1960;  New  York,  1970  (inactive) 


222 


HOSPITAL  APPOINTMENTS 

1965-69  Attending  Staff,  Parkland  Memorial  Hospital,  Dallas  TX 
1965-69  Attending  Staff,  John  Peter  Smith  Hospital,  Fort  Worth  TX 
1965-69  Attending  Staff,  Presbyterian  Hospital,  Dallas  TX 

1969- 72  Assistant  Attending  Staff,  Presbyterian  Hospital,  New  York  NY 

1970- 72  Attending  Surgeon,  Nangarhar  Univ,  Faculty  of  Medicine  Hospital,  Jalalabad,,  Afghanistan 

1972- 82  Attending  Surgeon,  Chief,  Surgery  B  Service,  Hermann  Hospital,  Houston  TX 

1 973- 82  Medical  Director  of  Emergency  Center,  Hermann  Hospital,  Houston,  Texas 

1976-  Founder  and  Medical  Director  of  Life  Flight  Operations,  Hermann  Hospital,  Houston  TX 

1 984-87  Medical  Director,  Affiliated  Hospital  Systems,  Hermann  Hospital,  Houston  TX 

1990-  Attending  Surgeon,  Surgery/Trauma  Service,  Hermann  Hospital,  Houston  TX 

1990-  Director  of  Trauma/Emergency  Medical  Services,  Hermann  Hospital,  Houston  TX 

1990-  Attending  Surgeon,  Harris  Cty  Hospital  District,  Lyndon  B,  Johnson  General  Hospital,  Houston  TX 

PROFESSIONAL  EXPERIENCE 

Professional  Organizations:  American  Board  of  Surgery,  American  College  of  Surgeons,  American  Medical 
Association,  American  Association  for  the  Surgery  of  Trauma,  American  Trauma  Society,  Association  for 
Academic  Surgery,  Association  of  American  Medical  College,  Division  of  International  Medical  Education, 
Chirurgio  Society,  Harris  County  Medical  Society,  Houston  Gastroenterological  Society,  Houston  Gulf  Coast 
Chapter  of  the  Ileitis  &  Colitis  Foundation,  Houston  Surgical  Society,  National  Association  for  Physician 
Broadcasters,  Society  for  Surgery  of  the  Alimentary  Tract,  Southeastern  Surgical  Congress,  Southern  Surgical 
Association,  Texas  Medical  Association,  Texas  Surgical  Society,  Current  Committees:  Texas  Department  of 
Health,  Emergency  Health  Care  Advisory  Committee;  American  Trauma  Society,  Board  of  Directors;  American 
College  of  Surgeons  Cancer  Liaison  Physician.  Hermann  Hospital:  Emergency  Medical  Services  Administrators 
Forum;  Trauma  Reporting  Ling/Performance  Improvement,  Co-Chairman;  Trauma  Surgery  Service  Focus 
Committee;  Level  I  Verification  Team;  Trauma  Resuscitation  Video  Review,  Quality  Audit, 

CURRENT  RESEARCH  PROJECTS 
Disaster  Relief  and  Emergency  Medical  Services  Project  (DREAMS™) 

An  Open-Label,  Multicenter  Clinical  Study  to  Evaluate  the  Efficacy  and  Safety  of  Technetium  Tc-99m  LeuTech 
Scintigraphy  for  the  Detection  of  Appendicitis  in  Patients  Presenting  with  Equivocal  Signs  and  Symptoms. 
Phase  II  Clinical  Trial  Evaluating  the  Safety  and  Efficacy  of  Technetium  Tc  99m  P748  in  the  Detection  and 
Localization  of  Pulmonary  Embolism  by  Gamma  Scintigraphy 
A  Phase  2b  Study  to  Evaluate  the  Safety  and  Efficacy  of  r-PAF-AH  for  Prevention  of  ARDS  in  Patients  with 
Severe  Sepsis  or  Severe  Traumatic  Injuries 

Phase  2B  Safety  and  Efficacy  Study  of  HU23F2G  in  Subject  with  Hemorrhagic  Shock  Technetium  Tc99m 
Leutech  Scintigraphy  for  Detection  of  Appendicitis 

PUBLICATIONS  (selected) 

Duke,  James  H.,  Jr.  Biochemical  Effects  of  Injury,  In:  Emergency  Medical  Managements:  The  Twenty-First 
Hahnemann  Symposium,  edited  by  Stanley  Spitzer,  W.  W.  Oaks  and  J.  H.  Moyer.  Grune  &  Stratton,  New 
York,  pp  182-196, 1971, 

Dudrick,  S.J.,  and  Duke,  James  H.,  Jr.  Parenteral  Nutrition-intravenous  Hyperalimentation.  In:  Gastroenterology, 
edited  by  H.L.  Bockus.  W.B,  Saunders  Company  Philadelphia,  pp  395-416, 1975. 

Duke,  James  H,,  Jr,,  and  Dudrick,  S.J.:  Parenteral  Feeding,  In  A.C.S.  Manual  of  Surgical  Nutrition,  edited  by  W. 

F,  Ballinger,  W.  B.  Saunders  Company:Philadelphia,  pp  285-317, 1975. 

Dudrick,  S.J.,  MacFadyen,  B.V.,  Jr.,  Copeland,  E.  M.,  and  Duke,  James  H.,  Jr.  Experimental  Aspects  of  Total 
Parenteral  Alimentation.  In:  Total  Parenteral  Alimentation,  Proceedings  of  the  International  Symposium  on 
Intensive  Therapy,  Rome  Italy,  May,  1975,  edited  by  C.  Manni,  S.I.  Magalini,  and  E.  Scrascia.  pp  3-17,  1976. 
Bloss,  R.S.,  Miller,  T.A.,  and  Duke,  James  H.,  Jr.  Eosinophilic  Infiltration  of  the  Stomach.  South.  Med.  J. 
73(5):672-674,  May  1980. 


223 


Duke,  James  H.,  Jr,:  The  High  Altitude  Dilemma:  Pressing  Schedules  versus  Acute  Mountain  Sickness.  KYH 
25:(2)20-23, 1980. 

Duke,  James  H.,  Jr.:  The  High  Altitude  Dilemma:  Pressing  Schedules  versus  Acute  Mountain  Sickness.  Part  II. 
KYH  25:(3)20-25, 1980. 

Duke,  James  H.,  Jr.,  and  Miller  T.A.:  Salt  and  Water:  Fluid  and  Electrolyte  Problems.  In  Surgical  Care:  A 
Physiologic  Approach  to  Clinical  Management,  edited  by  Condon,  R.  E.  and  DeCosse,  J.J.,  Lea  &  Fibiger, 
Philadelphia,  pp  36-369, 1980. 

Duke,  James  H.,  Jr.,  and  Clarice,  W.P.  Initial  Experience  of  a  University  Staffed  Private  Hospital  Based  Air 
Transport  Service.  Arch.  Surg.  116:703-708,  May,  1981. 

Duke,  James  H.,  Jr.:  Pancreatoduodenal  Injuries.  In:  Management  of  Difficult  Surgical  Problems,  edited  by 
Miller,  T.A.,  and  Dudrick,  S.J.,  University  of  Texas  Press,  Austin,  pp  239-259, 1981. 

Ward,  R.W.,  Miller,  P.W.,  Clark,  D.G.,  Ben-Menachem,  Y.,  and  Duke,  James  H.,  Jr.  Angiography  and  Peritoneal 
Lavage  in  Blunt  Abdominal  Trauma.  J.  Trauma  21:848-853, 1981. 

Gilliland,  M.,  Barton,  R.,  Ward,  R.,  Clark,  D.G.  Duke,  James  H.,  Jr.,  Miller,  P.W,  Factors  Affecting  Mortality  in 
Pelvic  Fractures.  J.  Trauma  22:691-693,  August  1982. 
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Duke,  James  H.,  Jr.,  and  Miller,  T.A,  Fluid  and  Electrolyte  Management.  In:  A.C.S,  Manual  of  Pre-  and 
Postoperative  Care,  3rd  Edition.  Saunders  Company,  Philadelphia,  pp  38-67,  1983. 

Kim,  E.,  McConnell,  B.,  McConnell,  R.,  and  Duke,  James  H.,  Jr.  Radionuclide  Diagnosis  of  Diaphragmatic 
Rupture  with  Hepatic  Herniation.  Surg.  94  (l);36-40,  July  1983. 

Scott,  L.D.,  Katz,  A.R.,  Duke,  James  H.,  Jr.,  Cowan,  D.  F.,  and  Maklad,  N.F.  Oral  Contraceptives,  Pregnancy,  and 
Focal  Nodular  Hyperplasia  of  the  Liver.  JAMA  251(1 1):  1461-1463,  March  1984, 

Fischer,  R.  P.,  Flynn,  T.C.,  Miller,  P.W.,  and  Duke,  James  H.  Jr.  Urban  Helicopter  Response  to  the  Scene  of 
Injury.  J.  Trauma  24(1 1):946-951, 1984. 

Walker,  W.E.,  Kapelanski,  D.P.,  Weiland,  A.  P.,  Stewart,  J.D.,  and  Duke,  James  H.,  Jr.  Patterns  of  Infection  and 
Mortality  in  Thoracic  Trauma.  Ann.  Surg.  201(6):752-757,  June  1985. 

Duke,  James  H.,  Jr.:  The  Significance  of  Early  and  Appropriate  Transport  Systems  for  the  Acutely  Injured.  In: 
Trauma  and  Critical  Care  Surgery,  edited  by  Delaney,  J.P.,  Year  Book  Publishers,  Chicago,  pp  19-28, 1987. 
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Critical  Care  Surgeiy,  edited  by  Delaney,  J.P.,  Year  Book  Publishers:Chicago,  pp  73-80, 1987. 
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Provide  the  following  information  for  the  key  personnel  listed  on  the  budget  page. 


NAME 

Elmer  V.  Bemstam,  MD 


POSITION  TITLE 
Clinical  Assistant  Professor 


EDUCATION/TRAINING  (Begin  with  baccalaureate  or  other  initial  professional  education,  such  as 


INSTITUTION  AND  LOCATION 

DEGREE  (IF 
APPLICABLE) 

YEAR(S) 

FIELD  OF  STUDY 

University  of  Michigan,  Ann  Arbor 

BS 

1992 

Biomedical  Sciences, 

University  of  Michigan,  Ann  Arbor 

BSE 

1992 

Psychology 

University  of  Michigan,  Ann  Arbor 

MD 

1995 

Computer  Engineering 

University  of  Michigan,  Ann  Arbor 

Stanford  University,  Stanford,  CA  (National 

MSE 

1999 

Computer  Engineering 

Library  of  Medicine  Post-Doctoral  Fellowship) 

MS 

2001 

Biomedical  Informatics 
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order,  previous  employment,  experience,  and  honors.  Include  present  membership  on  any  Federal  Government 
public  advisory  committee.  List  in  chronological  order,  the  titles,  all  authors,  and  complete  references  to  all 
publications  during  the  past  3  years  and  to  representative  earlier  publication  pertinent  to  this  application.  If  the  list 
of  publications  in  the  to  3  years  exceeds  2  pages,  select  the  most  pertinent  publications.  PAGE  LIMITATIONS 
APPLY.  DO  NOT  EXCEED  3  PAGES  FOR  THE  ENTIRE  BIOGRAPHICAL  SKETCH  PER 
INVESTIGATOR. 

PROFESSIONAL  EXPERIENCE 

1989-95  Research  Assistant,  School  of  Public  Health,  University  of  Michigan,  Ann  Arbor 
1995-98  Internal  Medicine  Resident,  St.  Joseph’s  Mercy  Hospital,  Ann  Arbor  MI 

1 998-  Attending  Physician,  St  Joseph’s  Mercy  Hospital,  Ann  Arbor,  Michigan 

1 998-  1 999  Attending  Physician,  Packard  Community  Clinic,  Ann  Arbor,  Michigan 

1999- 01  NLM  Post-Doctoral  Fellow,  Stanford  Medical  Informatics,  Stanford  Univ,  Stanford  CA 

1999-2001  Attending  Physician,  Stanford  University  Hospitals  and  Clinics,  Stanford,  California 

200 1-  Clinical  Assistant  Professor,  University  of  Texas  Health  Science  Center  t  Houston 

2002-  Faculty,  W.  M.  Keck  Center  for  Computational  Biology 

HONORS  AND  AWARDS 

1990  Eta  Kappa  Nu  electrical  and  computer  engineering  honor  society 
1992  B.S.  Biomedical  sciences  and  psychology  awarded  with  distinction 
1992  B.S.E.  Computer  Engineering  awarded  Magna  cum  laude 
1998  Diplomate,  American  Board  of  Internal  Medicine 

2001  Best-poster  in  category  at  the  Biomedical  Computation  at  Stanford  (BCATS  2001)  symposium 
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Assn  Proceedings  of  Annual  Conference,  San  Antonio  TX,  p,  75-82,  June  6-10, 1993. 
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origin,  case  report  and  literature  review.  American  College  of  Physicians,  Michigan  Chapter,  Abstract.  Traverse 
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September  28-9, 2000. 
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Conference,  Stanford,  CA,  October  28, 2000  [won  best  poster  in  category  prize]. 

Bemstam  EV,  Ash  N,  Peleg  M,  Tu  S,  Boxwala  AA,  Mork  P  Shortliffe  EH,  Greenes  RA.  Guideline 

classification  to  assist  modeling,  authoring,  implementation  and  retrieval.  Proceedings  of  the  AMIA  Fall 
Symposium  pp.  66-70, 2000. 

Peleg,  M,  Boxwala  AA,  Ogunyemi  O,  Zeng  Q,  Tu  SW,  Lacson  R,  Bemstam  E,  Ash  N,  Mork  P,  Ohno-Maehado 
L,  Shortliffe  EH,  Greenes  RA.  GLIF3;  The  evolution  of  a  guideline  representation.  Proceedings  of  the  AMIA 
Fall  Symposium  pp.  645-9, 2000. 

Elkin  P,  Peleg  M,  Lacson  R,  Bemstam  E,  Tu  S,  Boxwala  A,  Greenes  R,  Shortliffe  EH.  Toward  the 
Standardization  of  Electronic  Guidelines.  (2000)  MD  Computing,  17:6,  pp.  39-44. 

Peleg  M,  Boxwala  AA,  Bemstam  EV,  Tu  SW,  Greenes  RA,  Shortliffe  EH.  Sharable  Representation  of  Clinical 
Guidelines  in  GLIF:  Relationship  to  the  Arden  Syntax.  Journal  of  Biomedical  Informatics,  34:3, 170-181, 

2001. 

Meric  F,  Bemstam  EV,  Mirza  NQ,  Musen  MA.  Quality  and  accuracy  of  breast  cancer  information  on  the  World 
Wide  Web.  24th  Annual  San  Antonio  Breast  Cancer  Symposium  December  10-13, 2001 

Bemstam  EV,  Kamvar  SD,  Meric  F,  Dugan  JM,  Chang  JT,  Chizek  SC,  Stave  C,  Troyanskaya  OG  and  Fagan  LM. 
Oncology  Patient  Interface  to  MEDLINE.  Proceedings  of  the  American  Society  of  Clinical  Oncology  37th 
Annual  Meeting  20:244a  (abstract  974),  2001. 

Meric  F,  Bemstam  EV,  Mirza  NQ,  Hunt  KK,  Ames  FC,  Ross  MI,  Kuerer  HM,  Pollock  RE,  Musen  MA  and 
Singletary  SE.  Breast  Cancer  on  the  World  Wide  Web:  Determinants  of  Web  Site  Popularity.  Proceedings  of 
the  American  Society  of  Clinical  Oncology  37th  Annual  Meeting  20:39b  (abstract  1 904),  2001. 

Bemstam  EV.  Medline  Query-by-Example  (QBE)  Proceedings  of  the  AMIA  Fall  Symposium  pp.  47-52, 2001. 

Bemstam  EV ,  Ash  N,  Peleg  M,  Tu  S,  Shortliffe  EH,  Greenes  RA.  Preliminary  evaluation  of  a  guideline 
classification  system.  Proceedings  of  the  AMIA  Fall  Symposium  pp.  863, 2001. 

Phillips  RC,  Bemstam  EV,  Mode  P,  Lober  WB,  Karras  BT.  Modification  of  GEM  to  incorporate  changes  in  a 
classification  scheme.  Proceedings  of  the  AMIA  Fall  Symposium  pp.  994, 2001. 

Sagaram  S,  Walji  W,  Bemstam  EV.  Evaluating  the  prevalence,  content  and  readability  of  complementary  and 
alternative  medicine  (CAM)  web  pages  on  the  Internet.  Proceedings  of  the  AMIA  Fall  Symposium  2002,  in 
press. 

Michea  Y,  Pancehri  K,  Gong  Y,  Bemstam  EV.  Availability  of  online  communication  technology  on  diabetes  web 
sites:  comparing  Chinese,  English  and  Spanish  web  sites.  Proceedings  of  the  AMIA  Fall  Symposium  2002,  in 
press. 

Meric  F,  Bemstam  EV,  Mirza  NQ,  Hunt  KK,  Ames  FC,  Ross  MI,  Kuerer  HM,  Pollock  RE,  Musen  MA, 
Singletary  SE.  Breast  Cancer  on  the  World  Wide  Web:  A  Cross-sectional  survey  of  Information  Quality  and 
Web  Site  Popularity.  BMJ,  in  press. 
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1995—98  Center  Faculty,  Center  for  Cognitive  Science,  The  Ohio  State  University 

1997-98  Associate  Professor,  The  Ohio  State  University  Department  of  Pathology,  Division  of  Medical 
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Smith,  J,  W.  &  Johnson,  T.  R.  (1993).  A  stratified  approach  to  specifying,  designing,  and  building  knowledge 
systems.  IEEE  Expert,  8(3),  15-25. 

Chandrasekaran,  B.  &  Johnson,  T.  R.  (1993).  Generic  tasks  and  task  structures:  History,  critique  and  new 
directions.  In  J.-M.  David,  J.-P.  Krivine,  &  R.  Simmons  (Eds.),  Second  Generation  Expert  Systems  (pp.  232- 
272).  Berlin:  Springer-Verlag. 

Johnson,  T.  R,,  Smith,  J.  W.  &  Chandrasekaran,  B.  (1993).  Task-specific  architectures  for  flexible  systems.  In  P. 
S.  Rosenbloom,  J.  E.  Laird,  &  A.  Newell  (Ed.),  The  Soar  Papers:  Research  on  Integrated  Intelligence  (pp.  1004- 
1026).  Cambridge,  Mass:  MIT  Press. 

Johnson,  T.  R.,  Krems,  J,  &  Amra,  N.  K.  (1994).  A  computational  model  of  human  abductive  skill  and  its 
acquisition.  In  A.  Ram  &  K.  Eiselt  (Ed.),  Proceedings  of  the  Sixteenth  Annual  Conference  of  the  Cognitive 
Science  Society  (pp.  463-468).  Lawrence  Erlbaum  Associates. 

Johnson,  T.  R.  &  Smith,  J.  W.  (1994).  Abduction  in  Soar.  In  J.  R,  Josephson  &  S.  G.  Josephson  (Eds.),  Abductive 
Inference:  Computation,  Philosophy,  Technology  (pp.  105-116),  Cambridge:  Cambridge  University  Press. 

Johnson,  T.  R,  (1997).  Control  in  Act-R  and  Soar.  In  M.  Shafto  &  P.  Langley  (Eds.),  Proceedings  of  the 
Nineteenth  Annual  Conference  of  the  Cognitive  Science  Society  (pp.  343-348):  Hillsdale,  NJ:  Lawrence 
Erlbaum  Associates. 


227 


PUBLICATIONS  (continued) 

Johnson,  T,  R,,  Zhang,  J.,  &  Wang,  H.  (1997),  A  hybrid  learning  model  of  abductive  reasoning.  In  R.  Sun  &  F. 
Alexandre  (Eds.),  Connectionist  Symbolic  Integration  (pp.  91-112).  Mahwah,  NJ:  Lawrence  Erlbaum 
Associates. 

Johnson,  T.  R.,  Wang,  H.,  &  Zhang,  J.  (1998).  Modeling  speed-up  and  transfer  of  declarative  and  procedural 
knowledge,  Proceedings  of  the  Twentieth  Annual  Meeting  of  the  Cognitive  Science  Society.  Hillsdale,  NJ: 
Lawrence  Erlbaum. 

Zhang,  J.,  Johnson,  T.  R.,  &  Wang,  H.  (1998).  Isomorphic  representations  lead  to  the  discovery  of  different  forms 
of  a  common  strategy  with  different  degrees  of  generality.  In  M.  A.  Gemsbacher  &  S.  J.  Derry  (Eds.), 
Proceedings  of  the  Twentieth  Annual  Meeting  of  the  Cognitive  Science  Society  (pp.  1188-1 193).  Hillsdale,  NJ: 
Lawrence  Erlbaum. 

Wang,  H.,  Johnson,  T.  R.,  &  Zhang,  J.  (1998).  UEcho:  A  model  of  uncertainty  management  in  human  abductive 
reasoning.  In  M.  A.  Gemsbacher  &  S.  J.  Derry  (Eds.),  Proceedings  of  the  Twentieth  Annual  Meeting  of  the 
Cognitive  Science  Society  (pp.  1 113-1 118).  Hillsdale,  NJ:  Lawrence  Erlbaum. .  [This  paper  won  the  1998  Man- 
Prize  for  best  Student  paper] 

Johnson,  T.  R.  (1998).  Acquisition  and  transfer  of  declarative  and  procedural  knowledge.  In  F.  E.  Ritter  &  R.  M. 
Young  (Eds.),  Proceedings  of  the  Second  European  Conference  on  Cognitive  Modelling  (pp.  15-22). 
Nottingham,  UK:  Nottingham  University  Press, 

Zhang,  J,,  Johnson,  T.  R.,  &  Wang,  H.  (1998).  Order  effects  and  frequency  learning  in  tactical  decision  making. 
Thinking  and  Reasoning,  4(2),  123-125. 

Aoki,  N.,  Shek,  M.  C.,  Johnson,  T.  R.,  Sehreiber,  M.,  Holcomb,  J.  B.,  Wall,  M.  J.,  Cone,  R.  W.,  &  Beck,  J.  R. 
(2000).  Multiperspective  Comparison  Of  Abbreviated  injury  Scale  (AIS),  International  Classification  of 
Diseases,  and  Diagnosis  Related  Groups,  AMIA  2000  Annual  Symposium. 

Wang,  H.,  Zhang,  J.,  &  Johnson,  T.  R.  (2000).  Order  Effects  in  Human  Belief  Revision.  In  Proceedings  of  the 
Twenty  Second  Annual  Conference  of  the  Cognitive  Science  Society.  Hillsdale,  NJ:  Lawrence  Erlbaum. 
Johnson,  T.  R.,  Wang,  H.,  &  Zhang,  J.  (2000).  Declarative  and  Procedural  Learning  in  Alphabetic  Retrieval.  In 
Proceedings  of  the  Twenty  Second  Annual  Conference  of  the  Cognitive  Science  Society.  Hillsdale,  NJ: 
Lawrence  Erlbaum. 

Johnson,  C.,  Johnson,  T.  R.,  &  Zhang,  J.  (2000).  Increasing  Productivity  and  Reducing  Errors  through  Usability 
Analysis:  A  Case  Study  and  Recommendations,  Proceedings  of  the  American  Medical  Informatics  Association 
Annual  Symposium.  Hillsdale,  NJ:  Lawrence  Erlbaum  Associates. 

Chuah,  J.,  Zhang,  J.,  &  Johnson,  T.  R.  (2000).  The  Representational  Effect  in  Complex  Systems:  A  Distributed 
Representation  Approach,  Proceedings  of  die  Twenty  Second  Annual  Meeting  of  the  Cognitive  Science 
Society. 

Turley,  J.  P.,  Johnson,  C.,  Johnson,  T.,  &  Zhang,  J.  (2001).  A  clean  slate:  initiating  a  graduate  program  in  health 
informatics.  MD  Computing,  18(1),  47-48.. 

Johnson,  T.  R.,  Turley,  J.  P,,  &  Patel,  V.  L.  (2001).  Cognitive  Differences  in  Chart  Reading:  A  Comparison  of 
Nurses  and  Physicians.  In  Proceedings  AMIA  Fall  Symposium. 

Johnson,  T.  R,,  &  Krems,  J.  F.  (2001).  Use  of  current  explanations  in  multicausal  abductive  reasoning.  Cognitive 
Science,  25, 903-939. 

Johnson,  T.  R.,  Wang,  H.,  Zhang,  J.,  &  Wang,  Y.  (2002).  A  model  of  spatio-temporal  coding  of  memory  for 
multidimensional  stimuli.  In  W.  Gray  &  C,  Sehunn  (Eds.),  Proceedings  of  the  Twenty-Fourth  Annual 
Conference  of  the  Cognitive  Science  Society  (pp.  506-511).  Mahweh,  NJ:  Lawrence  Erlbaum  Associates. 
Wang,  H.,  Johnson,  T.  R.,  Zhang,  J.,  &  Wang,  Y.  (2002).  A  study  of  object  location  memory.  In  W.  Gray  &  C. 
Sehunn  (Eds.),  Proceedings  of  the  Twenty-Fourth  Annual  Conference  of  the  Cognitive  Science  Society  (pp. 
920-925).  Mahweh,  NJ:  Lawrence  Erlbaum  Associates, 

Zhang,  J.,  Patel,  V.  L.,  Johnson,  T.  R.,  &  Shortliffe,  E.  H.  (2002).  Toward  an  action  based  taxonomy  of  human 
errors  in  medicine.  In  W.  Gray  &  C.  Sehunn  (Eds.),  Proceedings  of  the  Twenty-Fourth  Annual  Conference  of 
the  Cognitive  Science  Society  (pp.  970-975).  Mahweh,  NJ:  Lawrence  Erlbaum  Associates. 

Johnson,  T.  R.,  Wang,  H.,  &  Zhang,  J.  Skill  Acquisition:  Models.  Encyclopedia  of  Cognitive  Science,  in  press. 
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Chair  Arden  Syntax  SIG,  2001-;  Clinical  Guidelines  Special  Interest  Group  (new  in  2001),  2001-.  The 
University  of  Texas  Health  Science  Center  at  Houston,  School  of  Medicine,  Wireless  Networking  Committee 

2000- . 

Teaching  Responsibilities:  HI  5303,  Clinical  Decision  Making,  The  University  of  Texas  Health  Science  Center  at 
Houston,  School  of  Health  Information  Sciences.  Director,  Informatics  Training  Course,  Center  for  Trauma 
Informatics  Research  and  Development,  The  University  of  Texas  Health  Science  Center  at  Houston,  School  of 
Medicine. 
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Symposium  on  Computer  Applications  in  Medical  Care.  Philadelphia:  Hanley  &  Belfus,  Inc.,  1995. 

East,  TD,  Wallace,  CJ,  Franklin,  MA,  Kinder,  AT  Sailors,  RM,  Carlson,  D,  Bradshaw,  R,  Morris,  AH.  Medical 
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care  reform.  In:  Gardner  RM,  ed.  Proceedings  of  the  19th  Annual  Symposium  on  Computer  Applications  in 
Medical  Care.  Philadelphia:  Hanley  &  Belfus,  Inc,  1995. 

Sailors,  RM,  East,  TD,  Wallace,  CJ,  Carlson,  DA,  Franklin,  MA,  Heermann,  LK,  Kinder,  AT,  Bradshaw,  RL, 
Randolph,  AG,  and  Morris,  AH.  Testing  and  validation  of  computerized  decision  support  systems.  Proc  AMIA 
Annu  Fall  Symp  1996, 234-8, 1996. 

Morris  AH,  East,  TD,  Wallace,  CJ,  Franklin,  M,  Heermann,  L,  Kinder,  T,  Sailors,  RM,  Carlson,  D,  and 
Bradshaw,  R.  Standardization  of  clinical  decision  making  for  the  conduct  of  credible  clinical  research  in 
complicated  medical  environments.  Proc  AMIA  Annu  Fall  Symp  199:418-22, 1996. 

East,  TD,  and  Sailors,  RM.  Clinical  information  systems  in  critical  care  (Chapter  5).  In:  Rane  M,  ed.  Clinical 
Information  Systems.  Redmond,  WA:  SpaceLabs  Medical,  Inc.  47-93, 1997. 

Sailors,  RM,  and  East,  TD.  The  role  of  the  computer  in  monitoring  (Chapter  76),  In:  Tobin  MJ,  ed.  Principles  and 
Practice  of  Critical  Care  Monitoring,  First  ed.  New  York  City:  McGraw-Hill,  Inc,  Health  Professions  Division. 
1329-1354,  1997. 

Sailors,  RM,  East  TD,  Clinical  informatics:  2000  and  beyond.  Journal  of  the  American  Medical  Informatics 
Association.  6(Symposium  Supplement  1999):609-613, 1999 

East,  TD,  Heermann,  LK,  Bradshaw,  RL,  Lugo,  A,  Sailors,  RM,  Ershler,  L,  Wallace,  CJ,  Morris,  AH,  McKinley, 
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